Secção Bibliotecas

A secção Bibliotecas permite-lhe desenvolver uma biblioteca partilhada em local e vê-la nos micros que a consomem, sem a publicar num registo. O Aseptic constrói o seu artefacto e liga-o a cada consumidor. Suporta bibliotecas npm, Maven, Gradle e Python.

É uma secção com padrão lista + detalhe (como Micros): no lateral, o catálogo de bibliotecas; no centro, o detalhe editável da selecionada.

O que significa «ligar»

Depende da tecnologia, porque cada ecossistema resolve as suas dependências num sítio diferente. Não é você que escolhe o mecanismo: o Aseptic deduz-no do que a biblioteca é.

Tecnologia	Onde acaba o artefacto	O que desligar desfaz
npm	copiado sobre o node_modules/<pacote> do consumidor	apaga a cópia e restaura a pasta original
Maven e Gradle	o repositório local (~/.m2), de onde resolvem todos os consumidores	apaga essa versão do repositório local (o Maven volta a descarregá-la do remoto)
Python	a roda (.whl), instalada no ambiente virtual de cada consumidor	desinstala-a e reinstala a versão que lá estava antes

Nos três casos é reversível: cada ligação deixa uma marca, e desligar só desfaz o que o Aseptic colocou. Um artefacto que já lá estava — uma versão descarregada do registo — nunca é tocado.

Adicionar uma biblioteca

A partir do botão de adição (barra superior) —também oferecido no fundo vazio da secção quando ainda não há nenhuma—:

• Adicionar biblioteca — escolhe a pasta do repo. Assim que o faz, o Aseptic mostra-lhe o que reconheceu antes de adicionar seja o que for: a tecnologia, o nome do pacote, a versão e que micros do catálogo já o declaram. Se a pasta não for uma biblioteca que saiba construir, di-lo ali e não deixa continuar.
• Importar do Git — clona o repo e adiciona-a. Aqui não há pré-visualização: não há nada em disco para ver até depois de clonar.

A tecnologia deduz-se do repo: pom.xml → Maven, build.gradle → Gradle, package.json com name → npm, pyproject.toml/setup.py → Python. O pacote é o nome tal como o escreveria quem a consome: o name do package.json, groupId:artifactId em JVM, o nome de distribuição em Python.

O detalhe de uma biblioteca

Identidade e receita de build. Guarda-se sozinha (autosave com um pequeno atraso, como em Micros; pode desativar-se em Definições):

• Nome e Pacote.

• Tecnologia — a deduzida ao adicionar. Pode alterá-la se se enganou.

• Build — o comando que constrói o artefacto e o caminho do artefacto. Se não os declarar, usam-se os do perfil da sua tecnologia:

  Tecnologia	Build por omissão	Caminho do artefacto
  npm	npm run build	dist/<último segmento do pacote>
  Maven	${mvn} install -DskipTests	target
  Gradle	${gradle} publishToMavenLocal -x test	build/libs
  Python	python -m build --wheel	dist

• Consumidores — os micros que usam a biblioteca. Por omissão são detetados sozinhos lendo quem declara esse pacote (package.json, pom.xml, build.gradle, requirements.txt, pyproject.toml); pode fixá-los à mão (ids de micros separados por vírgula).

• Vigiar alterações — reconstrói e volta a ligar automaticamente ao mudar o código.

${mvn} e ${gradle} são substituídos pelo executável do repo: o seu wrapper (mvnw, gradlew) se o trouxer, o global caso contrário. Assim a receita vale igual em todas as máquinas da equipa.

Estado e ações

Por biblioteca:

Ação	O que faz
Instalar	Instala as dependências da biblioteca no seu repo (o build fá-lo sozinho se faltarem).
Construir	Gera o artefacto.
Ligar	Constrói e põe o artefacto onde cada consumidor o resolve (ver a tabela acima).
Desligar	Desfaz a ligação em cada consumidor e restaura o que lá estava antes.
Vigiar	Faz construir + ligar a quente a cada alteração. Precisa do motor ativo.

O estado de cada biblioteca (construída / por construir, ligada em N consumidores, em vigilância) vê-se na lista e no detalhe.

Ao vigiar, o Aseptic ignora o que o próprio build escreve — node_modules, target, build/, o ambiente virtual e as caches — para não entrar num ciclo de reconstrução sem fim.

Um aviso sobre Maven e Gradle

Em JVM o artefacto não vive no repo do consumidor, mas no seu repositório local. Isso tem duas consequências:

• A ligação vale para todos os micros de uma vez, estejam ou não no cenário.
• Se a sua biblioteca não deixar resolver a sua versão a partir do repo (um pom.xml que a herda com ${revision}, um group calculado num script do Gradle), a ligação dir-lho-á. Resolve-se declarando a versão no YAML da biblioteca (stack.version).

Repositório (Git)

Como em Micros, o detalhe de uma biblioteca inclui o seu Git: mudar de ramo, fazer fetch e pull (--ff-only). O acesso é de apenas leitura (nunca faz push), e se houver alterações por confirmar, o Aseptic avisa antes de mudar de ramo ou atualizar.

Se o repo não está em disco

Se a pasta de uma biblioteca foi movida, o detalhe marca-o e oferece relocalizar: escolhe a pasta nova e o caminho é guardado.

Não invasivo

O Aseptic não modifica o repo do consumidor nem o da biblioteca: não toca no seu package.json, pom.xml nem requirements.txt. O que toca é o que vive fora do Git — node_modules, o repositório local, o ambiente virtual — e sempre com marca para poder revertê-lo.

Em npm há uma exceção a ter em conta: um npm install no consumidor sobrepõe-se ao seu node_modules e leva a ligação à frente. O Aseptic deteta-o e volta a ligar no fim. Com Maven e Gradle não acontece, porque o artefacto não vive lá.

Eliminar uma biblioteca do catálogo não a desliga: se estava ligada, desligue-a antes a partir do detalhe.

A partir da CLI e do MCP

aseptic library detect/list/status/build/link/unlink/watch. As de apenas leitura (library_detect, library_list, library_status) estão também como tools do MCP.

Ver também

• Secção Micros · O espaço de trabalho e .aseptic/