Astro 7.3 é uma atualização de atrito. Não há uma grande sintaxe para reaprender; há soluções para três situações que aparecem quando o projeto sai do notebook e entra em automação: subir previews paralelos, fazer extensões respeitarem o logger do framework e finalizar corretamente respostas de workers personalizados na Cloudflare.
Previews paralelos deixam de disputar o mesmo lock
O comando astro preview usa um lock para impedir que instâncias concorrentes se confundam. Isso é útil no terminal, mas atrapalha testes end-to-end que sobem servidores isolados para workers ou shards diferentes. A opção --ignore-lock permite iniciar esses previews em paralelo.
astro preview --ignore-lock --port 4322
Há uma troca: instâncias criadas assim são temporárias e não ficam sob o gerenciamento normal de preview stop e preview status. O processo que iniciou o servidor precisa guardar seu PID, encerrar no teardown e liberar a porta mesmo quando o teste falhar.
Extensões passam a falar no mesmo tom do Astro
Serviços de imagem e provedores de cache personalizados agora recebem o logger do Astro. Antes, uma integração podia usar console.warn e ignorar nível, destino ou --silent. O resultado era CI ruidoso ou, no extremo oposto, uma extensão sem contexto para registrar diagnóstico.
Com o logger oficial, mensagens seguem a configuração do projeto. As implementações integradas de Sharp e cache em memória já foram adaptadas. Autores de extensão devem preferir o objeto fornecido, escolher níveis honestos e evitar logar URL assinada, cookie ou conteúdo sensível só porque o destino parece local.
finalize() completa a resposta de workers personalizados
No adaptador @astrojs/cloudflare, quem escreve um entrypoint customizado de Worker pode chamar finalize() depois de astro/fetch. A função aplica cookies e os padrões de cache da CDN que o caminho normal do adaptador acrescentaria à resposta.
Esse detalhe importa porque retornar a Response bruta pode parecer correto nos testes básicos e ainda perder comportamento na borda. Integrações com Hono já fazem a finalização automaticamente pelo middleware. Num entrypoint manual, ela precisa aparecer de forma explícita.
Quem deve atualizar primeiro
- Projetos com Playwright ou outro runner abrindo mais de um preview por job.
- Equipes que mantêm image services ou cache providers próprios.
- Aplicações Cloudflare com entrypoint customizado, especialmente quando cookies e cache variam entre local e produção.
A atualização pode ser feita com npx @astrojs/upgrade. Depois dela, rode build e preview, verifique se processos paralelos terminam corretamente e compare headers de resposta do Worker. Em extensões próprias, teste --silent e os níveis de log no CI.
Pequenas APIs, efeitos grandes no pipeline
Nenhum desses recursos muda a página que o visitante vê por si só. Eles tornam o ambiente ao redor mais previsível. Preview paralelo reduz serialização artificial. Logger compartilhado deixa a extensão obedecer às regras do processo. finalize() evita divergência sutil entre o caminho padrão e o Worker customizado.
É uma atualização voltada a quem sente o framework nas bordas: testes, plugins e adapters. E são justamente essas bordas que costumam transformar um projeto simples num pipeline cheio de exceções.