Next.js 16.3.1-canary.15 remet de l’ordre dans Turbopack et le cache de build

Après la 16.3.1-canary.10 du 9 août 2026, qui durcissait Turbopack sur un cas de constantes ambiguës, puis la 16.3.1-canary.11 publiée le 10 août 2026 à 23:48, qui revenait surtout sur deux bascules internes, la v16.3.1-canary.15 ressemble à une canary de stabilisation. Le changelog officiel liste 14 changements, dont trois à retenir pour un usage quotidien : ajout de clusters dans les heuristiques de chunking (découpage du code en paquets chargés séparément), correctif HMR pour des imports dynamiques (import() chargé à l’exécution) évalués depuis des layouts, et invalidation plus fine de certaines sources d’entrée Webpack mises en cache. (github.com)

Ce qui bouge vraiment dans Turbopack

Le changement le plus structurant est l’ajout de clusters aux heuristiques de chunking de Turbopack. La discussion technique de la pull request explique que Turbopack introduit une probabilité dédiée, nommée cluster_navigation_probability, pour modéliser le fait qu’une navigation a davantage de chances de rester dans un groupe de routes liées qu’entre routes sans lien. En clair : le moteur de découpage essaie mieux d’anticiper les transitions réellement probables entre pages, afin d’assembler les morceaux de code de manière plus cohérente. En parallèle, Next.js ajoute aussi de la documentation sur ces clusters, signe que ce mécanisme devient un élément assumé du comportement interne du bundler. (github.com)

HMR, layouts et cache : les irritants visés

Côté expérience développeur, la canary corrige un bug Turbopack sur le HMR des imports dynamiques évalués depuis des layouts — autrement dit un cas où une mise à jour à chaud pouvait mal se propager quand le chargement du module passait par la structure de page partagée de l’application. Le changelog mentionne aussi l’arrêt de la sérialisation de l’état de version HMR, ce qui touche la manière dont Next.js persiste cet état interne entre sessions de développement, même si la page GitHub consultable n’expose pas davantage de détail descriptif. Enfin, le correctif “Invalidate deferred Webpack entry sources” cible explicitement les entrées différées (sources préparées plus tard dans le pipeline de build) : le test associé vérifie que ces entrées prennent bien le contenu mis à jour, tandis qu’une source non différée reste en cache. (github.com)

Le retour du fallback mtime

Un autre correctif concret réintroduit un fallback mtime (modification time, c’est-à-dire la date de dernière modification d’un fichier). La pull request précise que Next.js essaye de déterminer l’ancienneté d’une version en analysant un fichier nommé CURRENT ; pour des anciennes versions, cette lecture peut échouer. Le correctif remet donc un repli sur le timestamp du fichier et ajoute un test. Si vous maintenez des environnements de build hétérogènes ou des caches anciens, c’est le genre de patch discret qui évite des comportements incohérents difficiles à diagnostiquer. (github.com)

Ce qu’il faut en faire

Pour une équipe en App Router (le routeur moderne de Next.js) qui teste déjà les canary, cette livraison est surtout intéressante si vous avez observé des bizarreries de rechargement à chaud, des écarts entre Turbopack et Webpack, ou des comportements de cache instables. Elle ne justifie pas à elle seule une adoption large en production, mais elle confirme la trajectoire du cycle 16.3.1 : moins de nouvelles fonctionnalités visibles, plus de réglages fins sur le moteur de build. Pour valider rapidement l’impact dans votre base, le plus simple est de rejouer vos scénarios à problèmes avec la canary courante. (github.com)

pnpm add next@v16.3.1-canary.15 react@latest react-dom@latest
pnpm next dev --turbopack