6 PRs para colocar um site no ar

Na semana passada terminamos com 5 agentes rodando, 800 testes, e nenhum pixel na tela. Essa semana colocamos a Sinal no ar. Parece um avanço linear. Não foi. Deploy é onde o otimismo de engenharia morre. Cada plataforma tem suas armadilhas, cada integração tem seus edge cases, e o espaço entre "funciona no localhost" e "funciona em produção" é maior do que parece.

De Vite para Next.js em um commit

O frontend original era uma SPA em Vite. Funcionava. Mas a Sinal precisa de SEO — newsletters indexadas, páginas de agentes rastreáveis, Open Graph tags dinâmicas. SSR não é opcional para um produto de conteúdo. A migração para Next.js 14 com App Router foi uma decisão sem volta.

Migramos tudo: landing page com 12 seções do design system, arquivo de newsletters com busca e filtros, páginas individuais de cada newsletter com rendering de Markdown rico, sistema de auth com registro, login, e sessões. Rotas dinâmicas para cada agente — /radar/[slug], /funding/[slug], /codigo/[slug], /mercado/[slug]. Content gating para incentivar cadastro. Cada página com metadata, JSON-LD, e OG images geradas dinamicamente.

O resultado: 540 testes frontend cobrindo componentes, libs, auth, e SEO. É mais teste do que a maioria dos projetos tem no frontend inteiro. A razão é prática — com 5 agentes produzindo conteúdo dinâmico, qualquer regressão no rendering afeta dezenas de páginas. Testes são a rede de segurança.

A guerra do Vercel

Colocar um monorepo Next.js no Vercel deveria ser trivial. Não foi.

PR #11: o primeiro deploy falhou porque o vercel.json tinha um ignoreCommand que bloqueava tudo. Removemos. PR #12: o Vercel não encontrava o pnpm. Adicionamos packageManager ao package.json. PR #13: o engine do Node não batia. Adicionamos .npmrc com engine-strict=false. Aí descobrimos que um package-lock.json órfão fazia o Vercel usar npm em vez de pnpm. Removemos. O build usava cd apps/web && next build — que não funcionava no Vercel porque o monorepo precisa de pnpm --filter @sinal/web build. Corrigimos. O outputDirectory estava duplicado. Corrigimos.

Seis PRs consecutivos. Cada uma resolvendo um problema que o anterior revelava. É frustrante, mas é a realidade de deploy em plataformas managed: a documentação cobre o caminho feliz, e cada monorepo tem suas particularidades que só aparecem no push.

Depois do deploy funcionar, ainda tinham os bugs visuais que só aparecem em produção. O glow do background do hero era invisível — a opacidade de 0.02 que funcionava no dev era arredondada para zero pelo build otimizado. Subimos para 0.04. O hero não ocupava a viewport inteira em Safari mobile — min-h-screen não considera a barra de navegação. Trocamos por min-h-dvh.