chore(deps): move build-only packages to devDependencies (closes #102)

[Guiroos]

O que mudou

Movi três pacotes de dependencies para devDependencies no package.json, mantendo os pins exatos:

• @serwist/next@9.5.11 — plugin do next.config.mjs, roda só no build
• serwist@9.5.11 — importado por app/sw.ts, que compila para public/sw.js (artefato estático, não é módulo de servidor)
• tailwindcss-animate@1.0.7 — plugin do Tailwind, consumido por tailwind.config.ts na geração do CSS

package-lock.json regenerado com npm install --package-lock-only: o diff mexe só em flags dev/devOptional, nenhuma versão resolvida trocou.

Adicionei um segundo it em __tests__/unit/dependencies.test.ts que falha quando qualquer entrada de dependencies tem todos os importadores em pontos de entrada de build (*.config.* da raiz, next.config.mjs, app/sw.ts).

Por que dessa forma

Seguindo a proposta da issue sem desvio.

• Edição manual, não npm i -D: as 41 entradas do package.json são pins exatos; npm i -D reescreveria com caret. Movi as linhas entre os blocos à mão.
• Estender o arquivo de teste existente e não criar um novo: rootConfigFiles() é exatamente a função cujo resultado o primeiro it trata como prova de uso em produção; a asserção nova precisa tratar o mesmo conjunto como contraprova. As duas definições têm que compartilhar a mesma lista — separá-las em arquivos distintos é como elas divergem depois. next.config.mjs (não casa com .config.) e app/sw.ts (está dentro de app/, varrido pela primeira checagem como se fosse runtime) entram na lista de build-entry explicitamente, com comentário registrando por quê.

A classificação de um pacote como dev no lockfile é por alcançabilidade a partir de dependencies, não por onde é declarado — por isso mover um único pacote de build arrastava toda a subárvore transitiva para o lado "produção".

Como testei

Todos os gates locais verdes (npm ci limpo antes):

• npm run lint ✓
• npm run format:check ✓
• npm run typecheck ✓
• npm test — 498 testes ✓
• npm run build ✓

Aceite da issue confirmado:

• npm audit --omit=dev: 1 low → found 0 vulnerabilities
• Contagem de pacotes "produção" do lockfile: 332 → 195 (−137)

Caso discriminante do gate (o que só a correção certa passa): movi tailwindcss-animate de volta para dependencies temporariamente e o novo it falhou com expected [ 'tailwindcss-animate' ] to deeply equal []; com a classificação correta, passa. O it pré-existente fica verde nos dois estados (o arquivo de config não sai do lugar), como a issue previu — por isso o gate novo era necessário.

Risco e o que NÃO foi coberto

• Risco baixo: npm ci instala dependencies e devDependencies juntas, então CI e Vercel recebem exatamente o mesmo conjunto instalado. O vercel.json já roda db:migrate (drizzle-kit, uma devDependency) no build — se devDeps não estivessem disponíveis no build, o deploy já estaria quebrado.
• Ordem em relação à [deps] @serwist/next não roda no build padrão do Next 16 (Turbopack) — nenhum service worker é gerado, e a Fase 3 do roadmap deu a migração por concluída #101 (aberta, PR fix: migra @serwist/next para configurator mode (closes #101) #111): a [deps] @serwist/next não roda no build padrão do Next 16 (Turbopack) — nenhum service worker é gerado, e a Fase 3 do roadmap deu a migração por concluída #101 migra @serwist/next para o configurator mode e adiciona @serwist/cli. Se aquele PR mergear primeiro, este precisa de rebase — as linhas de @serwist/next/serwist podem mudar de forma. Ambos os PRs mexem em package.json/package-lock.json, então há chance de conflito de merge; nenhum dos dois altera as mesmas linhas de lógica.
• test:integration não roda em PR (só em push para main) e esta mudança não afeta área coberta por ele (nenhuma query/action tocada).
• A prevenção estrutural (o gate) está coberta. Não há parte estrutural adicional deixada de fora.

Arquivos tocados

• package.json — 3 linhas movidas de dependencies para devDependencies
• package-lock.json — regenerado (só flags dev)
• __tests__/unit/dependencies.test.ts — novo it + helper buildEntryPoints()

🤖 Generated with Claude Code

---

Generated by Claude Code

[Guiroos]

Um único nit, não bloqueante — a mudança está correta e faz exatamente o que a #102 pede.

O que verifiquei e passou (worktree limpo, npm ci):

• Gate discriminante funciona de verdade. Revertendo os três pacotes para dependencies, o it novo falha com expected [ '@serwist/next', 'serwist', 'tailwindcss-animate' ] to deeply equal []; com a classificação correta, passa. O it pré-existente fica verde nos dois estados (os importadores em arquivos de config não somem). Não é ruído verde.
• Aceite da issue confere: npm audit --omit=dev → found 0 vulnerabilities; contagem de produção do lockfile 332 → 195, exatamente o alvo da #102.
• Diff do lockfile só mexe em flags dev/devOptional→dev — nenhuma versão resolvida nem integrity trocou.
• Sem risco de runtime: npm ci instala dev+prod juntas (CI e Vercel recebem o mesmo conjunto), e os três só são importados em tailwind.config.ts, next.config.mjs e app/sw.ts (que compila para o artefato estático public/sw.js).

O nit está no comentário inline — não altera o resultado do gate.

---

Generated by Claude Code