Build a partir do código

O repositório é um monorepo de workspaces npm. Não há project references de TypeScript e não há bundler: cada pacote compila com tsc e publica dist/.

Build

npm install     # instala todos os workspaces
npm run build   # build de todos
npm test        # vitest em todos

A ordem do build importa e já está fixada no script da raiz: core-edge → protocol → otel → connector-sdk → demo → connectors → o resto. O build por workspaces não é topológico, então sem esse pré-build o dist/ do runner não resolve os @rootpilot/*.

Os dois perfis de TypeScript

Nem todo pacote compila com as mesmas flags, e isso é deliberado.

Perfil	Pacotes	Flags
tsconfig.base.json	protocol, otel, connector-sdk, runner	strict cheio: noUncheckedIndexedAccess, exactOptionalPropertyTypes, verbatimModuleSyntax, isolatedModules.
tsconfig.migrated.json	connectors, core-edge	Igual, mas com noUncheckedIndexedAccess e exactOptionalPropertyTypes desligados.

O segundo perfil existe porque esses pacotes vieram de um monólito escrito só com strict: true. Ligar as duas flags geraria milhares de ! arriscados sobre código já testado, com ganho próximo de zero. Subir para strict cheio é hardening futuro, não dívida esquecida.

Convenções que o build assume

• ESM + NodeNext. "type": "module", e todo import relativo carrega a extensão .js.
• Dependências honestas. Cada pacote declara só o que importa; zod é peerDependency apenas onde é de fato usado.
• Testes. vitest em todos. Nos pacotes migrados os testes ficam colocados em src/**/__tests__/*.test.ts para minimizar churn, uma divergência consciente em relação à convenção tests/ dos pacotes nativos.

Imagem do runner

docker build -f apps/runner/Dockerfile -t rootpilot-runner .

O contexto de build é a raiz do repositório, não apps/runner: o runner depende dos workspaces irmãos.

A imagem tem três estágios, e o terceiro é o que importa para você:

1. build: npm ci && npm run build.
2. prune: npm ci --omit=dev, que preserva os symlinks de workspace e derruba o toolchain.
3. runtime: copia apenas dist/, os package.json e as dependências de produção.

Duas armadilhas que já custaram caro

O runtime não copia o repositório inteiro. Já copiou, e isso levava src/, __tests__/ e fixtures para dentro da infra de produção de clientes, inclusive fixture de um cliente viajando para a infra de outro.

E o estágio de prune roda sem --ignore-scripts, obrigatoriamente: o runner depende de better-sqlite3, que é addon nativo. Pular o postinstall produz uma imagem que builda e morre no boot com Could not locate the bindings file, falha que não aparece em build nenhum, só na infra do cliente.

Publicação

Os @rootpilot/* são versionados por semver com retrocompatibilidade, o que é crítico para uma frota cattle, onde runners de versões diferentes convivem. publishConfig.access é public.