Novità

**Nuxt 3 è arrivato a fine vita il 31 luglio 2026.** L'annuncio è di Daniel Roe, manutentore principale del framework, nella release Nuxt 4.3.0 del 22 gennaio 2026. Se hai un'applicazione Nuxt 3 in produzione, quella data è ormai passata.

La prima cosa da chiarire è che cosa il fine vita **non** significa. Non si rompe nulla. La tua applicazione non ha smesso di funzionare il 1° agosto, nessun pacchetto è stato ritirato e `npm install` continua a funzionare. Il fine vita è un impegno di supporto che termina, non un interruttore.

Cosa significa davvero il fine vita

Quello che significa è che **Nuxt 3 non riceve più aggiornamenti di sicurezza né correzioni di bug critici**. Qualsiasi vulnerabilità divulgata d'ora in poi verrà corretta nella linea della versione 4 e non sarà riportata indietro. È tutto qui, e basta: un framework non aggiornato sul percorso delle richieste di un'applicazione pubblica è un debito che cresce in silenzio, secondo il calendario di altri e non il tuo.

In questa vicenda c'è un dettaglio che merita più attenzione di quanta ne riceva, perché dice qualcosa sulla migrazione stessa. **La data di fine vita iniziale era il 31 gennaio 2026.** I manutentori hanno aperto una discussione per capire come stesse andando davvero il passaggio dalla versione 3 alla 4, e quello che hanno sentito li ha portati a prolungare il supporto di sei mesi, proseguendo aggiornamenti di sicurezza e correzioni critiche oltre la data già annunciata.

È un gruppo di manutentori che si comporta bene, ed è anche un segnale da leggere senza giri di parole: l'aggiornamento era abbastanza difficile, per abbastanza persone, da giustificare lo spostamento di una scadenza pubblicata. Se lo stai rimandando da mesi, non sei solo e il progetto lo sapeva.

La scadenza già spostata una volta

Il corollario è meno comodo. **La proroga è stata usata.** Una scadenza già spostata una volta, dopo una consultazione pubblica, non è una scadenza da cui aspettarsi un secondo rinvio. Contarci significherebbe contare sulla buona volontà.

• `nuxt/4/file-structure` - le modifiche alla struttura delle cartelle introdotte nella versione 4
• `nuxt/4/default-data-error-value` - il nuovo valore predefinito di data ed error
• `nuxt/4/deprecated-dedupe-value` - rimozione dei valori di dedupe deprecati
• `nuxt/4/shallow-function-reactivity` - reattività superficiale per le funzioni
• `nuxt/4/absolute-watch-path` - i percorsi osservati diventano assoluti
• `nuxt/4/template-compilation-changes` - modifiche nella compilazione dei template

Dall'altra parte della migrazione, la release stabile attuale è **Nuxt 4.5.1**. L'aggiornamento parte da un solo comando, che la documentazione fornisce per ogni gestore di pacchetti: `npx nuxt upgrade`, o gli equivalenti `yarn`, `pnpm`, `bun x` e `deno x`.

Quel comando sposta la dipendenza. Non riscrive il codice, ed è lì che sta la maggior parte del lavoro vero. Nuxt pubblica **codemod ufficiali** per questa parte, raccolti in un'unica ricetta di migrazione: `npx codemod@0.18.7 nuxt/4/migration-recipe`. Nota la versione fissata. La documentazione la blocca di proposito invece di usare `@latest`, perché la trasformazione che esegui sia quella collaudata su questa migrazione.

La ricetta raccoglie diversi codemod singoli, e vale la pena conoscerli separatamente, perché una base di codice ampia spesso richiede di applicarli uno alla volta anziché tutti insieme. Eccoli.

Aggiornare: il comando e i codemod

Niente di tutto questo rende la migrazione automatica. I codemod gestiscono modifiche meccaniche, riconoscibili da uno schema; non ragionano sulla tua applicazione, sui tuoi moduli né sui pacchetti di terze parti nel tuo albero delle dipendenze, che hanno i propri tempi di compatibilità. Metti in conto del tempo per ciò che uno strumento non può vedere. Ma la parte meccanica è davvero coperta, ed è proprio quella che più spesso si dà per scontato di dover fare a mano.