Next.js 16.3.1-canary.10 durcit Turbopack sur un cas de constantes ambiguës
La canary **v16.3.1-canary.10** de Next.js a été publiée le **9 août 2026**. Son changelog public ne contient qu’un seul changement : côté **Turbopack** (le bundler, c’est-à-dire l’outil qui analyse et assemble votre code), certaines constantes dont la valeur référence une autre valeur sont désormais traitées comme **unsafe** (« non sûres » pour les optimisations automatiques). ([github.com](https://github.com/vercel/next.js/releases/tag/v16.3.1-canary.10))
Fil « Next.js canary 16.3.1-canary.10 »
La release v16.3.1-canary.10 est une préversion canary de Next.js, taguée par next-js-bot le 9 août 2026 à 23:23 sur GitHub. Le changelog affiché pour cette version est minimal : « [turbopack] Treat constants with values referencing other values as unsafe: #96190 » avec un remerciement explicite à @sampoder. Aucun autre changement n’est listé dans cette publication. (github.com)
Ce qui change concrètement
Le point important est le mot unsafe. Dans un bundler comme Turbopack, cela désigne typiquement une valeur que l’outil ne peut plus considérer comme suffisamment simple ou stable pour appliquer certaines transformations automatiques en toute confiance — par exemple de la propagation de constantes (remplacer une constante par sa valeur) ou du calcul statique à l’avance. Ici, la note indique que des constantes dont la valeur dépend d’une autre valeur entrent désormais dans cette catégorie. La release ne donne pas d’exemple de code ni de détail d’algorithme, mais elle formalise bien un durcissement de l’analyse plutôt qu’une nouvelle API applicative. (github.com)
Pourquoi cela peut vous concerner
Si vous testez déjà Next.js 16.3 canary avec Turbopack, cette évolution peut toucher les projets qui s’appuient sur des constantes chaînées, de la configuration factorisée, ou des chemins de code où le bundler tentait d’inférer trop agressivement une valeur à la compilation. L’effet attendu, d’après l’intitulé du changement, est moins de prises de risque dans l’analyse statique — donc potentiellement moins d’optimisations spéculatives, mais aussi moins de mauvaises déductions. Comme il s’agit d’une canary, il faut surtout y voir un correctif de comportement interne pour les équipes qui valident les versions avancées, pas une migration à lancer en production par défaut. (github.com)
Ce que je ferais côté équipe
Pour une équipe web qui suit Next.js de près, le bon réflexe est simple :
- ne pas surinterpréter cette release, car le changelog public ne documente qu’un ajustement interne ;
- tester vos builds canary si vous avez déjà adopté Turbopack sur des applications réelles ;
- surveiller en priorité les zones où vous avez des constantes indirectes (une constante définie à partir d’une autre) ;
- comparer, en cas d’écart, le comportement entre Turbopack et webpack (l’ancien bundler historique). (github.com)
Un test rapide peut ressembler à ceci :
const BASE = process.env.NEXT_PUBLIC_API_BASE
const API_URL = BASE
export async function getData() {
return fetch(`${API_URL}/items`)
}
Dans ce genre de motif, la release suggère que Turbopack sera désormais plus conservateur dans sa façon de raisonner sur API_URL si sa valeur dépend d’une autre référence. Je précise que cet exemple illustre le type de forme visée, pas un cas officiellement documenté par la release elle-même. La seule certitude publique, à ce stade, est le changement de classification introduit par #96190 dans v16.3.1-canary.10. (github.com)