Section Bibliothèques

La section Bibliothèques vous permet de développer une bibliothèque partagée en local et de la voir dans les micros qui la consomment, sans la publier dans un registre. Aseptic construit son artefact et le lie à chaque consommateur. Elle prend en charge les bibliothèques npm, Maven, Gradle, Python, Go et .NET.

C’est une section avec un pattern liste + détail (comme Micros) : sur le côté, le catalogue de bibliothèques ; au centre, le détail éditable de celle sélectionnée.

Ce que « lier » veut dire

Cela dépend de la technologie, car chaque écosystème résout ses dépendances à un endroit différent. Vous ne choisissez pas le mécanisme : Aseptic le déduit de ce qu’est la bibliothèque.

Technologie	Où atterrit l’artefact	Ce que délier défait
npm	copié sur le `node_modules/<paquet>` du consommateur	supprime la copie et restaure le dossier d’origine
Maven et Gradle	le dépôt local (`~/.m2`), d’où résolvent tous les consommateurs	supprime cette version du dépôt local (Maven la retélécharge depuis le distant)
Python	la roue (`.whl`), installée dans l’environnement virtuel de chaque consommateur	la désinstalle et réinstalle la version qui s’y trouvait avant
.NET	le dossier global de NuGet (`~/.nuget/packages`), d’où résolvent tous les consommateurs	supprime cette version du dossier global (le prochain restore la ramène)
Go	nulle part : un `go.work` dans le dépôt du consommateur pointe vers le module local	retire cette entrée du `go.work` (et le fichier entier en déliant la dernière)

Dans les six cas c’est réversible : chaque lien laisse une marque, et délier ne défait que ce que Aseptic a posé. Un artefact déjà présent — une version téléchargée du registre — n’est jamais touché.

Ajouter une bibliothèque

Depuis le bouton d’ajout (barre supérieure) —également proposé dans le fond vide de la section quand il n’y en a pas encore— :

Ajouter une bibliothèque — vous choisissez le dossier du dépôt. Dès que vous le faites, Aseptic vous montre ce qu’il a reconnu avant d’ajouter quoi que ce soit : la technologie, le nom du paquet, la version et quels micros du catalogue le déclarent déjà. Si le dossier n’est pas une bibliothèque qu’il sait construire, il le dit là et ne laisse pas continuer.
Importer depuis Git — clone le dépôt et l’ajoute. Ici il n’y a pas d’aperçu : il n’y a rien sur le disque à regarder tant que le clonage n’est pas fait.

La technologie se déduit du dépôt : pom.xml → Maven, build.gradle → Gradle, package.json avec name → npm, pyproject.toml/setup.py → Python, go.mod → Go, *.csproj → .NET. Le paquet est le nom tel que l’écrirait celui qui la consomme : le name du package.json, groupId:artifactId en JVM, le nom de distribution en Python, le chemin de module en Go (github.com/acme/core) et l’id du paquet en .NET.

Le détail d’une bibliothèque

Identité et recette de build. Elle s’enregistre toute seule (autosave avec un léger délai, comme dans Micros ; ça peut être désactivé dans Paramètres) :

Nom et Paquet.
Technologie — celle déduite à l’ajout. Vous pouvez la changer si elle s’est trompée.

Build — la commande qui construit l’artefact et le chemin de l’artefact. Si vous ne les déclarez pas, ceux du profil de sa technologie sont utilisés :

Technologie	Build par défaut	Chemin de l’artefact
npm	`npm run build`	`dist/<dernier segment du paquet>`
Maven	`${mvn} install -DskipTests`	`target`
Gradle	`${gradle} publishToMavenLocal -x test`	`build/libs`
Python	`python -m build --wheel`	`dist`
Go	`go build ./...`	le dépôt lui-même (`.`)
.NET	`dotnet pack -c Release`	`bin/Release`

Consommateurs — les micros qui utilisent la bibliothèque. Par défaut, ils sont détectés tout seuls en lisant qui déclare ce paquet (package.json, pom.xml, build.gradle, requirements.txt, pyproject.toml, le require du go.mod, le PackageReference d’un .csproj) ; vous pouvez les fixer à la main (ids de micros séparés par des virgules).
Surveiller les changements — reconstruit et relie automatiquement à chaque modification du code.

${mvn} et ${gradle} sont remplacés par l’exécutable du dépôt : son wrapper (mvnw, gradlew) s’il en fournit un, le global sinon. Ainsi la recette vaut pareil sur toutes les machines de l’équipe.

État et actions

Par bibliothèque :

Action	Ce qu’elle fait
Installer	Installe les dépendances de la bibliothèque dans son dépôt (le build le fait tout seul si elles manquent).
Construire	Génère l’artefact.
Lier	Construit et pose l’artefact là où chaque consommateur le résout (voir le tableau ci-dessus).
Délier	Défait le lien chez chaque consommateur et restaure ce qu’il y avait avant.
Surveiller	Fait construire + lier à chaud à chaque changement. Nécessite le moteur actif.

L’état de chaque bibliothèque (construite / non construite, liée dans N consommateurs, en surveillance) est affiché dans la liste et dans le détail.

En surveillance, Aseptic ignore ce qu’écrit le build lui-même — node_modules, target, build/, bin/, obj/, vendor/, l’environnement virtuel et les caches — pour ne pas entrer dans une boucle de reconstruction sans fin.

Un avertissement sur Maven et Gradle

En JVM, l’artefact ne vit pas dans le dépôt du consommateur, mais dans votre dépôt local. Cela a deux conséquences :

Le lien vaut pour tous les micros à la fois, qu’ils soient ou non dans le scénario.
Si votre bibliothèque ne laisse pas résoudre sa version depuis le dépôt (un pom.xml qui en hérite via ${revision}, un group calculé dans un script Gradle), le lien vous le dira. Cela se règle en déclarant la version dans le YAML de la bibliothèque (stack.version).

Un avertissement sur .NET

Comme en JVM, le paquet atterrit dans un magasin de la machine : le lien vaut donc pour tous les micros à la fois. Deux choses à savoir :

Le consommateur doit référencer la même version que la bibliothèque empaquette. S’il en référence une autre, celle-ci se résout depuis sa source habituelle et le lien ne se voit nulle part ; Aseptic vous le dit au lieu de laisser passer.
Lier restaure chaque consommateur une fois, avec le dossier de l’artefact ajouté à ses sources. C’est nécessaire : NuGet fait confiance à la copie qu’il a déjà, donc sans cette étape reconstruire la bibliothèque sans monter sa version ne changerait rien.

Un avertissement sur Go

En Go il n’y a pas d’artefact : une bibliothèque, ce sont ses sources, et c’est celui qui l’utilise qui les compile. Lier écrit un go.work dans le dépôt du consommateur avec un use qui pointe vers votre copie locale — l’endroit que Go réserve lui-même à cela (et pourquoi il recommande de ne pas le versionner). Si le consommateur avait déjà son go.work, il est mis de côté et revient intact en déliant la dernière bibliothèque. Son go.mod n’est pas touché : un replace aurait été plus court, mais il vit dans son fichier de dépendances et dans son historique Git.

Dépôt (Git)

Comme dans Micros, le détail d’une bibliothèque inclut son Git : changer de branche, faire fetch et pull (--ff-only). L’accès est en lecture seule (ne fait jamais de push), et s’il y a des changements non validés, Aseptic prévient avant de changer de branche ou de mettre à jour.

Si le dépôt n’est pas sur le disque

Si le dossier d’une bibliothèque a été déplacé, le détail le marque et propose de relocaliser : vous choisissez le nouveau dossier et le chemin est enregistré.

Non invasif

Aseptic ne modifie pas le dépôt du consommateur ni celui de la bibliothèque : il ne touche ni leur package.json, ni leur pom.xml, ni leur requirements.txt, ni leur go.mod, ni leur .csproj. Ce qu’il touche, c’est ce qui vit hors de Git — node_modules, le dépôt local, le dossier global de NuGet, l’environnement virtuel, le go.work — et toujours avec une marque pour pouvoir revenir en arrière.

En npm, une exception à connaître : un npm install chez le consommateur écrase son node_modules et emporte le lien avec lui. Aseptic le détecte et relie à la fin. Avec Maven et Gradle cela n’arrive pas, car l’artefact ne vit pas là.

Supprimer une bibliothèque du catalogue la délie d’abord : les services qui l’avaient liée retrouvent ce qu’ils avaient. Si l’un d’eux ne peut pas être délié, la bibliothèque n’est pas supprimée et l’avis indique lequel.

Depuis le CLI et le MCP

aseptic library detect/list/status/build/link/unlink/watch. Les lectures seules (library_detect, library_list, library_status) sont aussi disponibles comme outils du MCP.

Voir aussi

Section Micros · L’espace de travail et .aseptic/