Sezione Librerie

La sezione Librerie ti permette di sviluppare una libreria condivisa in locale e vederla nei micro che la consumano, senza pubblicarla in un registro. Aseptic costruisce il suo artefatto e lo collega a ogni consumatore. Supporta librerie npm, Maven, Gradle, Python, Go e .NET.

È una sezione con pattern lista + dettaglio (come Micro): sul lato, il catalogo di librerie; al centro, il dettaglio modificabile di quella selezionata.

Cosa vuol dire «collegare»

Dipende dalla tecnologia, perché ogni ecosistema risolve le sue dipendenze in un posto diverso. Non scegli tu il meccanismo: lo deduce Aseptic da cos’è la libreria.

Tecnologia	Dove finisce l’artefatto	Cosa annulla scollegare
npm	copiato sul `node_modules/<pacchetto>` del consumatore	cancella la copia e ripristina la cartella originale
Maven e Gradle	il repository locale (`~/.m2`), da cui risolvono tutti i consumatori	cancella quella versione dal repository locale (Maven la riscarica dal remoto)
Python	la ruota (`.whl`), installata nell’ambiente virtuale di ogni consumatore	la disinstalla e reinstalla la versione che c’era prima
.NET	la cartella globale di NuGet (`~/.nuget/packages`), da cui risolvono tutti i consumatori	cancella quella versione dalla cartella globale (il restore successivo la riporta)
Go	nessun posto: un `go.work` nel repo del consumatore punta al modulo locale	toglie quella voce dal `go.work` (e il file intero scollegando l’ultima)

In tutti e sei i casi è reversibile: ogni collegamento lascia un segno, e scollegare annulla solo ciò che ha messo Aseptic. Un artefatto che c’era già — una versione scaricata dal registro — non viene mai toccato.

Aggiungere una libreria

Dal pulsante di aggiunta (barra superiore) —offerto anche nello sfondo vuoto della sezione quando non ce n’è ancora nessuna—:

Aggiungi libreria — scegli la cartella del repo. Appena lo fai, Aseptic ti mostra ciò che ha riconosciuto prima di aggiungere qualsiasi cosa: la tecnologia, il nome del pacchetto, la versione e quali micro del catalogo lo dichiarano già. Se la cartella non è una libreria che sa costruire, te lo dice lì e non lascia continuare.
Importa da Git — clona il repo e la aggiunge. Qui non c’è anteprima: non c’è nulla su disco da guardare finché non si è clonato.

La tecnologia si deduce dal repo: pom.xml → Maven, build.gradle → Gradle, package.json con name → npm, pyproject.toml/setup.py → Python, go.mod → Go, *.csproj → .NET. Il pacchetto è il nome così come lo scriverebbe chi la consuma: il name del package.json, groupId:artifactId in JVM, il nome di distribuzione in Python, il percorso di modulo in Go (github.com/acme/core) e l’id del pacchetto in .NET.

Il dettaglio di una libreria

Identità e ricetta di build. Si salva da sola (autosave con un piccolo ritardo, come in Micro; si può disattivare in Impostazioni):

Nome e Pacchetto.
Tecnologia — quella dedotta all’aggiunta. Puoi cambiarla se ha sbagliato.

Build — il comando che costruisce l’artefatto e il percorso dell’artefatto. Se non li dichiari, si usano quelli del profilo della sua tecnologia:

Tecnologia	Build predefinita	Percorso dell’artefatto
npm	`npm run build`	`dist/<ultimo segmento del pacchetto>`
Maven	`${mvn} install -DskipTests`	`target`
Gradle	`${gradle} publishToMavenLocal -x test`	`build/libs`
Python	`python -m build --wheel`	`dist`
Go	`go build ./...`	il repo stesso (`.`)
.NET	`dotnet pack -c Release`	`bin/Release`

Consumatori — i micro che usano la libreria. Per impostazione predefinita vengono rilevati da soli leggendo chi dichiara quel pacchetto (package.json, pom.xml, build.gradle, requirements.txt, pyproject.toml, il require del go.mod, la PackageReference di un .csproj); puoi fissarli a mano (id di micro separati da virgola).
Sorveglia i cambiamenti — ricostruisce e ricollega automaticamente al cambiare del codice.

${mvn} e ${gradle} vengono sostituiti dall’eseguibile del repo: il suo wrapper (mvnw, gradlew) se lo porta, quello globale altrimenti. Così la ricetta vale uguale su tutte le macchine della squadra.

Stato e azioni

Per libreria:

Azione	Cosa fa
Installare	Installa le dipendenze della libreria nel suo repo (la build lo fa da sola se mancano).
Costruire	Genera l’artefatto.
Collegare	Costruisce e mette l’artefatto dove ogni consumatore lo risolve (vedi la tabella sopra).
Scollegare	Annulla il collegamento in ogni consumatore e ripristina ciò che c’era prima.
Sorvegliare	Fa costruire + collegare a caldo a ogni cambiamento. Richiede il motore attivo.

Lo stato di ogni libreria (costruita / non costruita, collegata in N consumatori, in sorveglianza) si vede nell’elenco e nel dettaglio.

Durante la sorveglianza, Aseptic ignora ciò che scrive la build stessa — node_modules, target, build/, bin/, obj/, vendor/, l’ambiente virtuale e le cache — per non entrare in un ciclo di ricostruzione senza fine.

Un avviso su Maven e Gradle

In JVM l’artefatto non vive nel repo del consumatore, ma nel tuo repository locale. Questo ha due conseguenze:

Il collegamento vale per tutti i micro insieme, che siano o meno nello scenario.
Se la tua libreria non lascia risolvere la sua versione dal repo (un pom.xml che la eredita con ${revision}, un group calcolato in uno script di Gradle), il collegamento te lo dirà. Si risolve dichiarando la versione nello YAML della libreria (stack.version).

Un avviso su .NET

Come in JVM il pacchetto finisce in un magazzino della macchina, quindi il collegamento vale per tutti i micro insieme. Due cose da sapere:

Il consumatore deve referenziare la stessa versione che la libreria impacchetta. Se ne referenzia un’altra, quella si risolve dalla sorgente di sempre e il collegamento non si vede da nessuna parte; Aseptic te lo dice invece di lasciar passare.
Collegare ripristina ogni consumatore una volta, con la cartella dell’artefatto aggiunta alle sue sorgenti. Serve: NuGet dà per buona la copia che ha già, quindi senza quel passo ricostruire la libreria senza alzarne la versione non cambierebbe nulla.

Un avviso su Go

In Go non c’è artefatto: una libreria sono i suoi sorgenti, e li compila chi la usa. Collegare scrive un go.work nel repo del consumatore con un use che punta alla tua copia locale, che è il posto che Go stesso riserva a questo (ed è per questo che consiglia di non versionarlo). Se il consumatore aveva già il suo go.work, viene messo da parte e torna intatto scollegando l’ultima libreria. Il suo go.mod non si tocca: un replace sarebbe stato più corto, ma vive dentro il suo file di dipendenze e la sua storia di Git.

Repository (Git)

Come in Micro, il dettaglio di una libreria include il suo Git: cambiare ramo, fare fetch e pull (--ff-only). L’accesso è di sola lettura (non fa mai push), e se ci sono modifiche non confermate, Aseptic avvisa prima di cambiare ramo o aggiornare.

Se il repo non è su disco

Se la cartella di una libreria è stata spostata, il dettaglio lo segnala e propone di rilocalizzare: scegli la nuova cartella e il percorso viene salvato.

Non invasivo

Aseptic non modifica il repo del consumatore né quello della libreria: non tocca il loro package.json, pom.xml, requirements.txt, go.mod o .csproj. Ciò che tocca è quello che vive fuori da Git — node_modules, il repository locale, la cartella globale di NuGet, l’ambiente virtuale, il go.work — e sempre con un segno per poterlo annullare.

In npm c’è un’eccezione da tenere presente: un npm install nel consumatore sovrascrive il suo node_modules e si porta via il collegamento. Aseptic lo rileva e ricollega alla fine. Con Maven, Gradle, .NET e Go non succede, perché ciò che il consumatore risolve non vive nel suo node_modules.

Eliminare una libreria dal catalogo prima la scollega: i servizi che la avevano collegata recuperano ciò che avevano. Se uno non può essere scollegato, la libreria non viene eliminata e l’avviso dice quale.

Dalla CLI e dal MCP

aseptic library detect/list/status/build/link/unlink/watch. Quelle di sola lettura (library_detect, library_list, library_status) sono anche disponibili come tool del MCP.

Vedi anche

Sezione Micro · Lo spazio di lavoro e .aseptic/