Next.js 16.3.1 stabilise une série de correctifs Turbopack et un bug concret de next/image

Après plusieurs canary suivies cette semaine, on peut enfin résumer simplement l’état de la branche 16.3.1 : la stable publiée le 13 août 2026 n’annonce pas de nouvelle API visible, mais consolide des correctifs internes autour de Turbopack et corrige un bug sur next/image. Le tag GitHub v16.3.1 a été créé sur le commit 3d32eb8 ; le changelog public liste notamment quatre changements : ne plus retirer le runtime (petit bout de code injecté à l’exécution) des async modules partagés, ajouter des ressources internes de turbopack_ecmascript et turbopack_wasm au mécanisme internal_assets_conditions, aplatir des promesses imbriquées dans l’analyseur, et préserver la réponse image après optimisation. (github.com)

Ce que la série 16.3.1 a changé depuis le début

Le point de départ public de cette séquence reste la canary 16.3.1-canary.10, publiée le 10 août 2026 à 07:16, avec un seul changement déclaré : Turbopack traite désormais comme unsafe (« non sûr » pour les optimisations automatiques) les constantes dont la valeur référence une autre valeur. Dit autrement, le moteur évite de faire des simplifications agressives quand une constante n’est pas assez triviale pour garantir qu’aucun effet de bord ne sera introduit au build. Cette base a ensuite été complétée par d’autres correctifs internes avant d’atterrir dans la stable 16.3.1. (github.com)

Pourquoi ces correctifs Turbopack comptent vraiment

Les intitulés du changelog montrent une priorité nette : fiabiliser le pipeline d’analyse et de génération plutôt qu’ajouter des fonctionnalités. Les trois correctifs Turbopack visibles dans la stable ciblent :

• le shared runtime chunk (morceau de runtime mutualisé entre plusieurs modules), qui ne doit plus perdre le support des async modules ;
• les ressources embarquées de turbopack_ecmascript et turbopack_wasm (WebAssembly, format binaire exécutable hors JavaScript) désormais incluses dans les conditions d’assets internes ;
• l’analyseur, qui « collapse nested promises », c’est-à-dire simplifie des promesses imbriquées pour éviter un traitement interne plus fragile ou plus complexe que nécessaire. (github.com)

Pour un développeur Next.js, la lecture pratique est claire : 16.3.1 vise surtout la robustesse des builds et du runtime de développement sur la nouvelle chaîne Turbopack. Ce n’est pas une release à adopter pour une nouveauté produit, mais une release à regarder si vous suivez déjà 16.x et que vous avez observé des comportements étranges autour de la compilation, des modules asynchrones ou d’assets internes. Cette interprétation reste une déduction à partir des correctifs publiés, pas une note officielle de l’équipe. (github.com)

Le correctif visible côté application : next/image

Le changement le plus concret pour une application en production est probablement fix(next/image): preserve image response after optimization, listé dans v16.3.1. GitHub expose bien l’intitulé du correctif dans la release stable, mais pas son explication détaillée sur la page de release consultable sans ouvrir la demande de fusion (pull request, c’est-à-dire la modification proposée puis relue avant intégration). On peut néanmoins relier ce point à une zone sensible connue du code serveur de Next.js : l’optimiseur d’images manipule la réponse amont, le type MIME (format annoncé par l’en-tête HTTP Content-Type) et l’etag (identifiant de version de la ressource pour le cache). Un correctif à cet endroit peut donc jouer sur la conservation correcte de la réponse une fois l’image optimisée. (github.com)

Si vous voulez vérifier rapidement que votre projet tourne bien sur cette version stable, la commande la plus simple reste :

npm install next@16.3.1

En bref : la branche 16.3.1 part d’un durcissement de Turbopack introduit en canary le 10 août 2026, puis aboutit le 13 août 2026 à une stable qui stabilise l’outillage, sans changement d’API majeur visible. Pour les équipes qui utilisent déjà Next.js 16, c’est typiquement une mise à jour de maintenance à évaluer en priorité si vous dépendez de Turbopack ou si vous avez un usage soutenu de next/image. (github.com)