Le compte à rebours de Nuxt 3 s'arrête le 31 juillet, pile quand Nuxt 4.5 sort

Il reste onze jours à Nuxt 3

Nuxt 3 atteint sa fin de vie le 31 juillet 2026, dans onze jours. Ce délai tombe onze jours après Nuxt 4.5, que les release notes qualifient de « plus grosse release depuis un moment », sortie le 18 juillet avec trois mises à jour de la couche de build (Vite 8, Rspack 2 sur un nouveau pipeline Rsbuild) plus un mode de streaming SSR expérimental.

Que les deux événements tombent aussi près l'un de l'autre n'est pas une coïncidence à sur-interpréter. Ça ressemble surtout à une équipe qui nettoie son plan de travail avant qu'une version ne devienne froide. Ce qui compte pour qui fait encore tourner du Nuxt 3 en prod est plus simple : la marge pour bouger se compte désormais en jours, pas en trimestres.

La dernière fenêtre de sortie facile

En parallèle de la 4.5.0, l'équipe Nuxt a livré v3.21.9, présentée comme l'une des dernières releases 3.x, avec un backport des correctifs compatibles de ce cycle. Après le 31 juillet, ce flux de backport s'arrête.

Le discours de l'équipe elle-même est que la migration v3 vers v4 s'est bien passée pour la plupart des équipes qui l'ont faite, et le guide de migration est à jour, mais « bien passée » suppose qu'on la fait avant que le filet de sécurité ne disparaisse : backports de patchs, guide de migration activement maintenu, attention de la communauté sur votre erreur précise. Si vous êtes encore sur du 3.x aujourd'hui, cette semaine est la version du « plus tard » que vous reportiez.

Vite 8 est une montée majeure déguisée en mineure

Le changement technique le plus visible : Nuxt tourne désormais sur Vite 8 par défaut, avec des cold starts plus rapides et des internals portés par Rolldown. Nuxt présente ça comme « transparent » pour la plupart des apps, vrai si votre stack ne dépasse pas la couche d'abstraction de Nuxt.

Si vous avez des plugins Vite custom, des réglages directs dans vite.config, ou des plugins tiers qui pinnent une version majeure de Vite, cette transparence ne tient plus. Vite 8 est une version majeure, et les versions majeures cassent des choses que les mineures ne cassent pas. Traitez cette mise à jour comme sensible à l'intégration, pas comme un bump de patch anodin, le même piège qui rattrape toute équipe supposant, à tort, que le semver seul protège des surprises.

Trois points concrets, dans l'ordre où ils vous arrêteront. D'abord le plus bête et le plus bloquant : nuxt@4.5.0 relève son plancher Node à ^22.19.0 || ^24.11.0 || >=26.0.0. Un .nvmrc à 20, un engines.node: >=20 ou un job CI resté sur Node 20 échoue avant même d'avoir vu Vite. Ensuite, la forme objet de manualChunks est supprimée en Vite 8, pas dépréciée : si votre rollupOptions.output.manualChunks est un objet nommant des vendor chunks, il faut le réécrire. Enfin, cssMinify: true bascule d'esbuild vers Lightning CSS, et le guide de migration prévient que la taille du CSS « might increase slightly » ; le repli est cssMinify: 'esbuild'. Ajoutez-y que c'est désormais Rolldown qui décide du chunking : si vos réglages de découpe viennent d'un audit Core Web Vitals daté, remesurez plutôt que de supposer l'iso-perf.

La réécriture de Rspack que personne ne remarquera, sauf en la débuggant

Plus intéressant que Vite 8 : ce qui est arrivé au builder Rspack, un vrai cas d'école. Nuxt a fait passer le builder sur Rspack 2 et l'a reconstruit sur @rsbuild/core, remplaçant webpack-dev-middleware et webpack-hot-middleware par un serveur de dev propulsé par Rsbuild tournant en mode middleware.

La surface publique (builder: 'rspack' dans la config, les hooks rspack:* existants) reste identique. Tout ce qu'il y a en dessous a changé. Voilà la version saine d'une réécriture interne cassante : l'équipe a gardé le contrat stable en vidant l'implémentation par en dessous, donc les équipes sur le builder Rspack récupèrent la mise à jour gratuitement et n'ont besoin de s'inquiéter que si ce serveur de dev en mode middleware se comporte différemment de l'ancien basé sur webpack.

Le travail de fond discret pour Nuxt 5

Sous les deux mises à jour phares se cache beaucoup de plomberie qu'on n'est pas censé remarquer : Nuxt passe à unhead v3 et unctx v3, fait tourner son propre build sur tsdown, et introduit un contrat de sortie de build nuxt/* stable, un contrat entre les builders et le framework, interne au monorepo Nuxt et sans effet sur le code applicatif, qui prépare l'adoption de la Vite Environment API.

Une nuance vaut d'être posée, parce qu'elle contredit le mot « plomberie » : passer à unhead v3 est un breaking change amont. content devient obligatoire sur les meta name / property / http-equiv, le type-narrowing se resserre sur useHead, et useServerHead / useServerSeoMeta disparaissent. En 4.5, Nuxt enregistre un shim de plugins legacy tant que compatibilityVersion vaut 4, donc le runtime ne bouge pas, mais le typecheck d'une app dense en useHead, lui, bouge. Une app à quarante ou cinquante fichiers de head est un meilleur détecteur du coût réel de cette release que n'importe quel benchmark de cold start.

Rien de tout ça ne livre une feature qu'on va utiliser directement. Ce que ça achète, c'est un écart plus court entre v4 et v5. L'objectif affiché de l'équipe est de rendre ce saut « aussi ennuyeux que possible », le même pari qui a rendu le passage v3 vers v4 indolore pour la plupart des équipes qui l'ont fait. Pour commencer à repérer tôt les breaking changes de v5, future.compatibilityVersion: 5 est déjà disponible en opt-in dans la 4.5.

Codes d'erreur stables : des diffs plus petits quand ça casse

Cette release livre aussi un système de codes d'erreur stables. Les erreurs de build et de runtime portent désormais un code fixe et greppable (NUXT_E1001, NUXT_B5001) avec une explication courte et un correctif suggéré, plutôt qu'un mur de texte à re-diagnostiquer de zéro à chaque fois.

Un petit changement, qui paie exactement au moment où vous êtes le moins patient : en plein incident, à grepper les logs. Un code stable, c'est quelque chose sur quoi épingler un runbook ; un paragraphe de prose, non.

Le streaming SSR vaut le test, avec un piège précis

La vraie nouvelle capacité, c'est le streaming SSR expérimental : au lieu de bufferiser tout le rendu de la page avant de l'envoyer, Nuxt flush le shell HTML immédiatement et streame le body au fur et à mesure que Vue le rend, ce qui devrait sensiblement réduire le time-to-first-byte sur les routes riches en contenu. Le streaming est en opt-in (experimental.ssrStreaming: true) et automatiquement désactivé pour les bots et crawlers, donc le SEO n'est pas un compromis à gérer à la main.

Le piège à connaître avant de l'activer : comme le streaming committe le status et les headers de la réponse dès le premier octet, tout ce qui mute la réponse après le début du rendu (un appel setResponseStatus(), une écriture de cookie en cours de rendu) n'arrive plus silencieusement jusqu'au client. Nuxt retombe automatiquement en rendu bufferisé dans une liste de cas plus large qu'on ne l'imagine : les routeRules redirect, cache, isr, swr, noScripts et streaming: false, les routes en ssr: false, les routes prérendues, les redirections navigateTo() côté serveur, et les erreurs fatales survenues avant le flush du shell. Il logue par ailleurs les mutations perdues en dev pour que l'échec ne soit pas silencieux, et vous pouvez désactiver le streaming route par route avec routeRules: { '/checkout/**': { streaming: false } }.

Le filet de sécurité est raisonnable, mais il a un revers : sur une app déjà largement couverte par de l'isr ou du swr (le réflexe par défaut sur Vercel) le streaming ne s'appliquera presque nulle part et le gain de TTFB sera nul. Les vrais candidats sont les routes dynamiques non cachées et riches en contenu. Auditez votre logique de mutation de réponse avant d'activer ça au-delà d'une simple page de contenu, et n'oubliez pas que vos modules en mutent aussi : nuxt-security (injection de nonce et headers via les hooks render:html / render:response), nuxt-seo-utils (minification du HTML complet) et @nuxtjs/i18n (detectBrowserLanguage écrit un cookie pendant le rendu) sont invisibles à un grep de votre seul dossier app/.

Sur quoi on parie la semaine prochaine

On active le streaming SSR sur nos propres routes riches en contenu pour voir ce que le gain de TTFB donne réellement face à une baseline bufferisée. Et on considère toute équipe encore pinnée sur Nuxt 3 après le 31 juillet comme portant un risque non patché par défaut, pas comme faisant un choix de style.

Si vous en faites partie, la lecture est celle-ci : l'attention de l'écosystème (compatibilité des plugins, correctifs communautaires, prochaines réponses Stack Overflow) bascule vers v4 dès que la branche 3.x arrête de livrer. Chaque semaine passée après le délai rend cette migration un peu moins « indolore » qu'elle ne l'aurait été aujourd'hui.

→ Contactez-nous — on audite votre app Nuxt 3 par rapport au guide de migration v4 et on livre la migration avant la fin du délai.