Aktuelles

**Nuxt 3 hat am 31. Juli 2026 sein End of Life erreicht.** Die Ankündigung stammt von Daniel Roe, dem leitenden Maintainer des Frameworks, im Release Nuxt 4.3.0 vom 22. Januar 2026. Wenn Sie eine Nuxt-3-Anwendung produktiv betreiben, ist dieses Datum inzwischen verstrichen.

Zuerst sollte klar sein, was End of Life **nicht** bedeutet. Nichts geht kaputt. Ihre Anwendung hat am 1. August nicht aufgehört zu laufen, kein Paket wurde zurückgezogen, und `npm install` funktioniert weiterhin. End of Life ist das Ende einer Support-Zusage, kein Abschalter.

Was End of Life wirklich bedeutet

Es bedeutet aber, dass **Nuxt 3 keine Sicherheitsupdates und keine kritischen Bugfixes mehr erhält**. Jede ab jetzt offengelegte Schwachstelle wird in der Version-4-Linie behoben und nicht zurückportiert. Mehr ist es nicht, und das genügt: ein ungepatchtes Framework im Anfrageweg einer öffentlichen Anwendung ist eine Last, die still wächst, nach dem Zeitplan anderer und nicht nach Ihrem.

In dieser Geschichte steckt ein Detail, das mehr Aufmerksamkeit verdient, denn es sagt etwas über die Migration selbst. **Der ursprüngliche EOL-Termin war der 31. Januar 2026.** Die Maintainer eröffneten eine Diskussion, um zu erfahren, wie der Umstieg von Version 3 auf Version 4 tatsächlich lief, und was sie hörten, führte dazu, den Support um sechs Monate zu verlängern und Sicherheitsupdates sowie kritische Bugfix-Releases über den bereits angekündigten Termin hinaus fortzuführen.

Das ist ein Maintainer-Team, das sich anständig verhält, und zugleich ein Signal, das man nüchtern lesen sollte: Das Upgrade war für genug Leute schwierig genug, um eine veröffentlichte Frist zu verschieben. Wenn Sie es vor sich herschieben, sind Sie nicht allein, und das Projekt wusste das.

Die Frist, die schon einmal verschoben wurde

Die Kehrseite ist unbequemer. **Die Verlängerung ist aufgebraucht.** Eine Frist, die nach einer öffentlichen Befragung bereits einmal verschoben wurde, ist keine Frist, bei der man mit einer zweiten Verschiebung rechnen sollte. Darauf zu bauen hiesse, auf Kulanz zu bauen.

• `nuxt/4/file-structure` - die in Version 4 eingeführten Änderungen der Verzeichnisstruktur
• `nuxt/4/default-data-error-value` - der neue Standardwert für data und error
• `nuxt/4/deprecated-dedupe-value` - Entfernung veralteter dedupe-Werte
• `nuxt/4/shallow-function-reactivity` - flache Reaktivität für Funktionen
• `nuxt/4/absolute-watch-path` - Watch-Pfade werden absolut
• `nuxt/4/template-compilation-changes` - Änderungen bei der Template-Kompilierung

Auf der anderen Seite der Migration ist **Nuxt 4.5.1** der aktuelle stabile Release. Das Upgrade beginnt mit einem einzigen Befehl, den die Dokumentation für jeden Paketmanager angibt: `npx nuxt upgrade`, beziehungsweise die Entsprechungen für `yarn`, `pnpm`, `bun x` und `deno x`.

Dieser Befehl verschiebt die Abhängigkeit. Er schreibt Ihren Code nicht um, und genau dort liegt die eigentliche Arbeit. Nuxt veröffentlicht dafür **offizielle Codemods**, gebündelt in einem einzigen Migrationsrezept: `npx codemod@0.18.7 nuxt/4/migration-recipe`. Beachten Sie die fixierte Version. Die Dokumentation pinnt sie bewusst statt `@latest` zu verwenden, damit die ausgeführte Transformation genau die ist, die gegen diese Migration getestet wurde.

Das Rezept bündelt mehrere einzelne Codemods, und es lohnt sich, sie einzeln zu kennen, denn eine grosse Codebasis verlangt oft, sie nacheinander statt auf einmal anzuwenden. Hier sind sie.

Upgrade: der Befehl und die Codemods

Nichts davon macht die Migration automatisch. Codemods erledigen mechanische, mustererkennbare Änderungen; sie schliessen nicht über Ihre Anwendung, Ihre Module oder die Drittpakete in Ihrem Abhängigkeitsbaum, die eigene Kompatibilitätsfahrpläne haben. Planen Sie Zeit für das ein, was ein Werkzeug nicht sehen kann. Der mechanische Teil aber ist wirklich abgedeckt, und gerade den glaubt man am häufigsten von Hand machen zu müssen.