Sección Librerías

La sección Librerías te permite desarrollar una librería compartida en local y verla en los micros que la consumen, sin publicarla en un registro. Aseptic construye su artefacto y lo enlaza a cada consumidor. Soporta librerías npm, Maven, Gradle, Python, Go y .NET.

Es una sección con patrón lista + detalle (como Micros): en el lateral, el catálogo de librerías; en el centro, el detalle editable de la seleccionada.

Qué significa «enlazar»

Depende de la tecnología, porque cada ecosistema resuelve sus dependencias en un sitio distinto. Tú no eliges el mecanismo: lo pone Aseptic según lo que sea la librería.

Tecnología	Dónde acaba el artefacto	Qué deshace desenlazar
npm	copiado sobre node_modules/<paquete> del consumidor	borra la copia y restaura la carpeta original
Maven y Gradle	el repositorio local (~/.m2), del que resuelven todos los consumidores	borra esa versión del repositorio local (Maven la vuelve a bajar del remoto)
Python	la rueda (.whl), instalada en el entorno virtual de cada consumidor	desinstala y reinstala la versión que hubiera antes
.NET	la carpeta global de NuGet (~/.nuget/packages), de la que resuelven todos los consumidores	borra esa versión de la carpeta global (el siguiente restore la vuelve a traer)
Go	ningún sitio: un go.work en el repo del consumidor apunta al módulo local	retira esa entrada del go.work (y el fichero entero al desenlazar la última)

En los seis casos es reversible: cada enlace deja una marca, y desenlazar solo deshace lo que puso Aseptic. Un artefacto que ya estaba ahí —una versión descargada del registro— no se toca.

Añadir una librería

Desde el botón de alta (barra superior) —también ofrecido en el fondo vacío de la sección cuando aún no hay ninguna—:

• Añadir librería — eliges la carpeta del repo. Al elegirla, Aseptic te enseña lo que ha reconocido antes de dar de alta nada: la tecnología, el nombre del paquete, la versión y qué micros del catálogo ya lo declaran. Si la carpeta no es una librería que sepa construir, te lo dice ahí y no deja continuar.
• Importar desde Git — clona el repo y lo da de alta. Aquí no hay vista previa: no hay nada en disco que mirar hasta después de clonar.

La tecnología se deduce del repo: pom.xml → Maven, build.gradle → Gradle, package.json con name → npm, pyproject.toml/setup.py → Python, go.mod → Go, *.csproj → .NET. El paquete es el nombre tal y como lo escribiría quien la consume: el name del package.json, groupId:artifactId en JVM, el nombre de distribución en Python, la ruta de módulo en Go (github.com/acme/core) y el id del paquete en .NET.

El detalle de una librería

Identidad y receta de build. Se guarda solo (autosave con un pequeño retardo, igual que en Micros; se puede desactivar en Ajustes):

• Nombre y Paquete.

• Tecnología — la deducida al dar de alta. Puedes cambiarla si se equivocó.

• Build — el comando que construye el artefacto y la ruta del artefacto. Si no los declaras se usan los del perfil de su tecnología:

  Tecnología	Build por defecto	Ruta del artefacto
  npm	npm run build	dist/<último segmento del paquete>
  Maven	${mvn} install -DskipTests	target
  Gradle	${gradle} publishToMavenLocal -x test	build/libs
  Python	python -m build --wheel	dist
  Go	go build ./...	el propio repo (.)
  .NET	dotnet pack -c Release	bin/Release

• Consumidores — los micros que usan la librería. Por defecto se detectan solos leyendo quién declara ese paquete (package.json, pom.xml, build.gradle, requirements.txt, pyproject.toml, el require del go.mod, el PackageReference de un .csproj); puedes fijarlos a mano (ids separados por coma).

• Vigilar cambios — reconstruye y reenlaza automáticamente al cambiar el código.

${mvn} y ${gradle} se sustituyen por el ejecutable del repo: su wrapper (mvnw, gradlew) si lo trae, el global si no. Así la receta vale igual en todas las máquinas del equipo.

Estado y acciones

Por librería:

Acción	Qué hace
Instalar	Instala las dependencias de la librería en su repo (el build lo hace solo si faltan).
Construir	Genera el artefacto.
Enlazar	Construye y pone el artefacto donde cada consumidor lo resuelve (ver la tabla de arriba).
Desenlazar	Deshace el enlace en cada consumidor y restaura lo que hubiera antes.
Vigilar	Hace construir + enlazar en caliente ante cada cambio. Necesita el motor vivo.

El estado de cada librería (construida / sin construir, enlazada en N consumidores, en watch) se ve en la lista y en el detalle.

Al vigilar, Aseptic ignora lo que escribe el propio build —node_modules, target, build/, bin/, obj/, vendor/, el entorno virtual y las cachés— para no entrar en un bucle de reconstrucción sin fin.

Un aviso sobre Maven y Gradle

En JVM el artefacto no vive en el repo del consumidor, sino en tu repositorio local. Eso tiene dos consecuencias:

• El enlace vale para todos los micros a la vez, estén o no en el escenario.
• Si tu librería no deja resolver su versión desde el repo (un pom.xml que la hereda con ${revision}, un group calculado en un script de Gradle), el enlace te lo dirá. Se arregla declarando la versión en el YAML de la librería (stack.version).

Un aviso sobre .NET

Como en JVM, el paquete acaba en un almacén de la máquina, así que el enlace vale para todos los micros a la vez. Dos cosas que conviene saber:

• El consumidor tiene que referenciar la misma versión que la librería empaqueta. Si referencia otra, esa se resuelve del origen de siempre y el enlace no se ve; Aseptic te lo dice en vez de dejarlo pasar.
• Al enlazar se restaura cada consumidor una vez, con la carpeta del artefacto añadida a sus orígenes. Es necesario: NuGet da por buena la copia que ya tiene, así que sin ese paso reconstruir la librería sin subirle la versión no cambiaría nada.

Un aviso sobre Go

En Go no hay artefacto: una librería son sus fuentes y las compila quien la usa. Enlazar escribe un go.work en el repo del consumidor con un use que apunta a tu copia local, que es el sitio que el propio Go reserva para esto (y por eso recomienda no versionarlo). Si el consumidor ya tenía su go.work, se aparta y vuelve intacto al desenlazar la última librería. No se toca su go.mod: un replace habría sido más corto, pero vive dentro de su fichero de dependencias y de su historia de Git.

Repositorio (Git)

Como en Micros, el detalle de una librería incluye su Git: cambiar de rama, hacer fetch y pull (--ff-only). El acceso es de solo lectura (nunca hace push), y si hay cambios sin confirmar, Aseptic avisa antes de cambiar de rama o actualizar.

Si el repo no está en disco

Si la carpeta de una librería se movió, el detalle lo marca y ofrece relocalizar: eliges la carpeta nueva y se guarda la ruta.

No invasivo

Aseptic no modifica el repo del consumidor ni el de la librería: no toca su package.json, su pom.xml, su requirements.txt, su go.mod ni su .csproj. Lo que toca es lo que está fuera de Git —node_modules, el repositorio local, la carpeta global de NuGet, el entorno virtual, el go.work—, y siempre con marca para poder revertirlo.

En npm hay una excepción a tener en cuenta: un npm install en el consumidor pisa su node_modules y se lleva el enlace por delante. Aseptic lo detecta y vuelve a enlazar al terminar. Con Maven, Gradle, .NET y Go no pasa, porque lo que resuelve el consumidor no vive en su node_modules.

Borrar una librería del catálogo no la desenlaza: si estaba enlazada, desenlázala antes desde el detalle.

Desde el CLI y el MCP

aseptic library detect/list/status/build/link/unlink/watch. Las de solo lectura (library_detect, library_list, library_status) están también como tools del MCP.

Ver también

• Sección Micros · El espacio de trabajo y .aseptic/