TypeScript 7.0 en prod : le compilateur Go et ses pièges
TypeScript 7.0 est en disponibilité générale depuis le 8 juillet. Une analyse approfondie publiée par InfoQ le 3 août 2026 fait le point sur l'état réel de la migration et les pièges qui attendent les équipes qui se précipitent vers la mise à jour.
Le gain de performance : réel, mais variable
Le compilateur Go tient ses promesses sur le papier. Microsoft annonce des gains "typiquement entre 8x et 12x" sur les builds complets, avec des cas emblématiques :
| Projet | TypeScript JS | TypeScript Go | Gain |
|---|---|---|---|
| VS Code (1,5M lignes) | 77,8 s | 7,5 s | 10,4x |
| Playwright | 11,1 s | 1,1 s | 10,1x |
| TypeScript lui-même | 125,7 s | 10,6 s | 11,9x |
Ces chiffres correspondent aux builds complets. Sur les projets de taille modeste (< 100k lignes), le gain perçu est moins dramatique car le temps de démarrage du compilateur représente une part plus faible du total.
Ce qui change (et casse) dans TypeScript 7
TypeScript 7 n'est pas qu'un changement de runtime — il embarque des breaking changes importants :
Fin du target ES5
TypeScript 7 ne peut plus compiler vers ES5. Si votre tsconfig.json contient "target": "es5", le build échoue avec une erreur explicite. Dans la pratique, ES5 n'est plus nécessaire depuis que IE11 est mort — mais les projets qui maintiennent un support legacy ou utilisent des outils anciens devront adapter leur configuration.
Solution : migrer vers "target": "es2017" ou supérieur.
Suppression de la résolution de modules node (legacy)
La stratégie "moduleResolution": "node" (l'ancienne, pré-Node16) est retirée. Seuls node16, nodenext et bundler sont supportés dans TS 7.
Suppression de AMD/UMD/SystemJS
Les formats de modules anciens disparaissent. Si votre build génère des modules en AMD ou UMD, il faudra migrer.
Mode strict par défaut
TS 7 active strict: true par défaut dans les nouveaux projets. Les projets existants avec un tsconfig.json gardent leurs paramètres — mais c'est un signal fort de Microsoft.
Le problème bloquant : pas d'API programmatique stable
C'est le piège majeur que l'analyse InfoQ met en lumière. TypeScript 7.0 ne livre pas d'API programmatique stable — la Compiler API que les outils utilisent pour analyser et transformer du TypeScript à la volée.
Cela signifie concrètement que les frameworks et outils suivants ne peuvent pas utiliser TS 7 aujourd'hui :
- Vue (Volar / vue-tsc)
- Angular (vérification de types des templates)
- Svelte (svelte-check)
- Astro (astro check)
- typescript-eslint
- ts-jest
Microsoft prévoit de livrer une nouvelle API programmatique dans TypeScript 7.1. D'ici là, ces outils restent bloqués sur TS 6.
Le chemin de migration recommandé
TypeScript 5.x → TypeScript 6 → TypeScript 7
L'étape TypeScript 6 est obligatoire : c'est elle qui signale chaque option supprimée dans TS 7 sous forme d'avertissement de dépréciation explicite. Migrer directement de TS 5 à TS 7 expose à des erreurs de compilation sans piste claire.
bash# Étape 1 : passer à TypeScript 6 npm install typescript@6 # Corriger tous les warnings de dépréciation # Mettre à jour tsconfig.json (target, moduleResolution) # Étape 2 : passer à TypeScript 7 npm install typescript@7
Est-ce que Next.js 16.3 peut en profiter ?
Oui — mais uniquement pour le type checking du build de production (next build). Turbopack utilise son propre pipeline de compilation basé sur esbuild/swc pour le dev, indépendamment de la version TypeScript installée. Le gain de vitesse de TS 7 ne s'applique donc qu'à tsc --noEmit et aux vérifications de types dans le build.
Verdict pour les projets React/Next.js standard
Pour un projet Next.js sans Vue, Angular ou Svelte dans la stack, la migration est réalisable maintenant si vous passez par l'étape TS 6. Le gain sur les builds de production justifie l'investissement pour les projets > 200k lignes de TypeScript.
Pour les projets qui dépendent de typescript-eslint ou ts-jest, il vaut mieux attendre TypeScript 7.1 et la nouvelle API programmatique.