Next.js 16 + Turbopack com Bun: Conflitos, Warnings e Correções em Produção

Migração para Next.js 16 com Turbopack aumenta velocidade de build, mas também pode elevar volume de warning. O erro operacional é tentar “zerar log” sem priorizar impacto. Neste post, documento o método que usei para classificar e corrigir alertas sem introduzir regressão.

Classificação de warning por criticidade

Eu separo em três níveis:

1. P1: afeta runtime/segurança (corrigir imediato);
2. P2: pode afetar compatibilidade (corrigir em janela curta);
3. P3: advisory/ecossistema (documentar e monitorar).

Caso 1: conflito de NODE_ENV

Warning de ambiente inconsistente:

You are using a non-standard "NODE_ENV" value...

Correção aplicada:

• remover NODE_ENV de .env;
• deixar next dev e next build definirem modo;
• usar variável própria para stage:

NEXT_PUBLIC_APP_STAGE=staging

Caso 2: baseline-browser-mapping desatualizado

bun add -d baseline-browser-mapping@latest

Se warning persistir e não afetar runtime, classifico como P3 e mantenho no backlog técnico com revisão periódica.

Caso 3: depreciação de middleware para proxy

Depreciação exige cuidado em apps com auth/edge rules. Fluxo que aplico:

1. validar suporte do SDK usado;
2. criar branch de migração de middleware -> proxy;
3. testar rotas protegidas e redirecionamentos;
4. liberar gradualmente.

Caso 4: erro "Package can't be external" com Bun

Em projetos com árvore de dependência profunda, o Turbopack pode falhar com:

Package agent-base can't be external...

Fluxo que resolveu no meu ambiente:

1. limpeza de cache e lock:

rm -rf .next node_modules bun.lock yarn.lock
bun pm cache rm

1. externalizar só pacotes pai em serverExternalPackages;
2. usar resolutions para achatar versões conflitantes;
3. rodar bun pm trust --all e regenerar Prisma quando aplicável.

Higiene de build e cache

Após mudanças estruturais:

rm -rf .next node_modules
bun install
bun run build

Isso evita falso positivo causado por cache antigo.

Observabilidade pós-mudança

Validações mínimas antes de produção:

• build sem erro fatal;
• smoke test de rotas críticas;
• monitoramento de 4xx/5xx na primeira hora;
• rollback pronto em release anterior.

Conclusão

No Next.js 16, maturidade não é “eliminar todo warning”. É tratar primeiro o que impacta runtime e segurança, documentar o que é ruído de ecossistema e manter pipeline previsível de correção sem quebrar rotas críticas.

Este post está licenciado sob CC BY-NC.