Notícias

**O Nuxt 3 chegou ao fim de vida a 31 de julho de 2026.** O anúncio foi feito por Daniel Roe, o principal responsável pela manutenção do framework, na versão Nuxt 4.3.0 publicada a 22 de janeiro de 2026. Se tem uma aplicação Nuxt 3 em produção, essa data já passou.

A primeira coisa a esclarecer é o que o fim de vida **não** significa. Nada se parte. A sua aplicação não deixou de funcionar a 1 de agosto, nenhum pacote foi retirado e o `npm install` continua a resolver. O fim de vida é um compromisso de suporte que termina, não um interruptor.

O que significa realmente o fim de vida

O que significa é que **o Nuxt 3 já não recebe atualizações de segurança nem correções de erros críticos**. Qualquer vulnerabilidade divulgada a partir de agora será corrigida na linha da versão 4 e não retroportada. É só isto, e chega: um framework sem correções no caminho dos pedidos de uma aplicação pública é um passivo que cresce em silêncio, ao calendário de outros e não ao seu.

Há nesta história um pormenor que merece mais atenção do que recebe, porque diz algo sobre a própria migração. **A data inicial de fim de vida era 31 de janeiro de 2026.** Os responsáveis abriram uma discussão para saber como estava realmente a correr a passagem da versão 3 para a 4, e o que ouviram levou-os a prolongar o suporte por seis meses, mantendo atualizações de segurança e correções críticas para além da data já anunciada.

É uma equipa de manutenção que se porta bem, e é também um sinal que convém ler sem rodeios: a atualização era suficientemente difícil, para gente suficiente, para justificar mexer num prazo publicado. Se anda a adiá-la há meses, não está sozinho e o projeto sabia disso.

O prazo que já foi adiado uma vez

O corolário é menos confortável. **A prorrogação já foi usada.** Um prazo que já foi movido uma vez, na sequência de uma consulta pública, não é um prazo de que se possa esperar um segundo adiamento. Contar com isso seria contar com a boa vontade.

• `nuxt/4/file-structure` - as alterações à estrutura de pastas introduzidas na versão 4
• `nuxt/4/default-data-error-value` - o novo valor por omissão de data e error
• `nuxt/4/deprecated-dedupe-value` - remoção dos valores de dedupe obsoletos
• `nuxt/4/shallow-function-reactivity` - reatividade superficial para funções
• `nuxt/4/absolute-watch-path` - os caminhos vigiados passam a ser absolutos
• `nuxt/4/template-compilation-changes` - alterações na compilação de templates

Do outro lado da migração, a versão estável atual é o **Nuxt 4.5.1**. A atualização começa com um único comando, que a documentação dá para cada gestor de pacotes: `npx nuxt upgrade`, ou os equivalentes em `yarn`, `pnpm`, `bun x` e `deno x`.

Esse comando move a dependência. Não reescreve o seu código, e é aí que está a maior parte do trabalho real. O Nuxt publica **codemods oficiais** para essa parte, reunidos numa única receita de migração: `npx codemod@0.18.7 nuxt/4/migration-recipe`. Repare na versão fixada. A documentação fixa-a de propósito em vez de usar `@latest`, para que a transformação que executa seja a que foi testada contra esta migração.

A receita junta vários codemods individuais, e vale a pena conhecê-los em separado, porque uma base de código grande costuma exigir aplicá-los um a um em vez de todos de uma vez. São estes.

Atualizar: o comando e os codemods

Nada disto torna a migração automática. Os codemods tratam de alterações mecânicas, reconhecíveis por um padrão; não raciocinam sobre a sua aplicação, os seus módulos nem os pacotes de terceiros da sua árvore de dependências, que têm calendários de compatibilidade próprios. Reserve tempo para aquilo que uma ferramenta não consegue ver. Mas a parte mecânica está mesmo coberta, e é justamente a que mais se assume que terá de ser feita à mão.