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 y Python.

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

En los tres 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. 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.

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

• 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); 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/, 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).

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 ni su requirements.txt. Lo que toca es lo que está fuera de Git —node_modules, el repositorio local, el entorno virtual—, 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 y Gradle no pasa, porque el artefacto no vive ahí.

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/