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.

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é. C'est 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 pour que le type-checking marche sans étape de build séparée.

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.

C'est 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. C'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é pour les routes utilisant redirect, cache, isr, swr, ou ssr: false, et logue les mutations perdues en dev pour que l'échec ne soit pas silencieux. C'est un filet de sécurité raisonnable, mais auditez votre logique de mutation de réponse avant d'activer ça au-delà d'une simple page de contenu.

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 honnête 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.