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, Python, Go e .NET.

É 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
.NET	a pasta global do NuGet (`~/.nuget/packages`), de onde resolvem todos os consumidores	apaga essa versão da pasta global (o restore seguinte volta a trazê-la)
Go	nenhum sítio: um `go.work` no repo do consumidor aponta para o módulo local	retira essa entrada do `go.work` (e o ficheiro inteiro ao desligar a última)

Nos seis 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, go.mod → Go, *.csproj → .NET. 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 caminho de módulo em Go (github.com/acme/core) e o id do pacote em .NET.

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`
Go	`go build ./...`	o próprio repo (`.`)
.NET	`dotnet pack -c Release`	`bin/Release`

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, o require do go.mod, a PackageReference de um .csproj); 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/, bin/, obj/, vendor/, 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).

Um aviso sobre .NET

Como em JVM, o pacote acaba num armazém da máquina, por isso a ligação vale para todos os micros de uma vez. Duas coisas a saber:

O consumidor tem de referenciar a mesma versão que a biblioteca empacota. Se referenciar outra, essa resolve-se da origem de sempre e a ligação não se vê; o Aseptic di-lo em vez de deixar passar.
Ao ligar restaura-se cada consumidor uma vez, com a pasta do artefacto acrescentada às suas origens. É necessário: o NuGet dá por boa a cópia que já tem, por isso sem esse passo reconstruir a biblioteca sem lhe subir a versão não mudaria nada.

Um aviso sobre Go

Em Go não há artefacto: uma biblioteca são as suas fontes e compila-as quem a usa. Ligar escreve um go.work no repo do consumidor com um use que aponta para a sua cópia local, que é o sítio que o próprio Go reserva para isto (e por isso recomenda não o versionar). Se o consumidor já tinha o seu go.work, é posto de lado e volta intacto ao desligar a última biblioteca. O seu go.mod não se toca: um replace teria sido mais curto, mas vive dentro do seu ficheiro de dependências e da sua história de Git.

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, requirements.txt, go.mod nem .csproj. O que toca é o que vive fora do Git — node_modules, o repositório local, a pasta global do NuGet, o ambiente virtual, o go.work — 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, Gradle, .NET e Go não acontece, porque o que o consumidor resolve não vive no seu node_modules.

Eliminar uma biblioteca do catálogo desliga-a antes: os serviços que a tinham ligada recuperam o que tinham. Se algum não puder ser desligado, a biblioteca não é eliminada e o aviso diz qual.

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/