🚀 TypeScript 7.0 : le compilateur passe au Go

📚 Introduction

Le 8 juillet 2026, l’équipe TypeScript a livré la version 7.0, et ce n’est pas une release comme les autres : c’est la première fois en plus de dix ans que le compilateur change de langage d’implémentation. Exit le TypeScript historique écrit en JavaScript, place à un portage natif en Go, surnommé tsgo.

Le projet n’est pas sorti de nulle part. TypeScript 6.0, publié en mars 2026, avait explicitement joué le rôle de « pont » : la plupart de ses changements de configuration n’avaient d’autre but que de préparer la bascule vers ce nouveau moteur. TypeScript 7.0 est donc l’aboutissement de cette transition, avec un objectif simple : diviser les temps de build par 8 à 12, sans rien changer au comportement de vérification de types que des millions de projets utilisent déjà.

🔍 Qu’est-ce qui change concrètement côté performance ?

Les chiffres publiés dans l’annonce officielle, mesurés sur des projets réels, donnent une idée de l’ampleur du gain :

La consommation mémoire baisse aussi de 6 à 26 % selon les projets. Mais le changement le plus perceptible au quotidien est ailleurs : l’ouverture d’un fichier contenant des erreurs dans VS Code, qui pouvait prendre 17,5 secondes avant que l’éditeur ne signale les problèmes, tombe sous 1,3 seconde. Le mode --watch a lui aussi été reconstruit, avec un portage en Go du watcher de Parcel, pour éliminer le polling coûteux sur les gros monorepos chargés en node_modules.

🧩 Un portage, pas une réécriture

C’est le point le plus important à comprendre pour faire confiance à cette migration : le code Go n’a pas été écrit à partir d’une feuille blanche. L’équipe l’a méthodiquement porté depuis l’implémentation JavaScript existante, fonction par fonction, en gardant une logique de type-checking structurellement identique à TypeScript 6.0. Le résultat a ensuite été confronté à la suite de tests accumulée en une décennie, puis testé en conditions réelles chez des entreprises comme Bloomberg, Figma ou Google avant la beta.

Concrètement, l’exécutable s’appelle tsgo et son développement se suit sur le dépôt microsoft/typescript-go, distinct du dépôt historique TypeScript.

🛠️ Installer et faire coexister les deux versions

L’installation ne change pas :

npm install -D typescript

Si un projet a besoin de garder temporairement TypeScript 6.0 en parallèle (le temps qu’un outil tiers rattrape son retard, par exemple), un alias de package permet la coexistence :

npm install -D typescript@npm:@typescript/typescript6

Les builds nightly, eux, restent disponibles via typescript@next.

Côté ligne de commande, quatre nouveaux flags pilotent le parallélisme du compilateur, qui tire justement parti du multithreading à mémoire partagée offert par Go :

• --checkers [nombre] — nombre de workers de vérification de types (4 par défaut)
• --builders [nombre] — nombre de constructeurs parallèles pour les project references
• --singleThreaded — désactive toute parallélisation
• --ignoreConfig — permet de lancer le compilateur sans tsconfig.json

⚠️ Quelques précautions avant de migrer

TypeScript 7.0 durcit des défauts déjà annoncés en 6.0 comme transition, et cette fois ils s’appliquent pour de bon :

• strict: true, module: esnext et types: [] par défaut — un projet qui comptait sur la découverte automatique des @types/* doit désormais lister explicitement ["node", "jest"] etc.
• rootDir vaut le dossier contenant le tsconfig.json : un projet dont les sources vivent hors de src/ doit le déclarer explicitement.
• Suppressions définitives : target: es5, downlevelIteration, les résolutions de modules classic/node (legacy), les formats amd/umd/systemjs, ainsi que baseUrl.
• Le typage des littéraux de template change pour respecter Unicode : découper `${infer Head}${infer Tail}` sur une chaîne commençant par un emoji renvoie désormais l’emoji entier, plus une paire de substituts UTF-16 coupée en deux.
• Côté JSDoc pour les projets en JavaScript pur, plusieurs patterns disparaissent : @enum (remplacé par @typedef), @class qui ne génère plus de constructeur, ou la syntaxe de fonction façon Closure.

Deux limites sont à connaître avant de basculer un projet entier. D’abord, il n’y a pas encore d’API programmatique : les outils qui embarquent TypeScript dans un autre langage de template — Vue (Volar), Astro, MDX, Svelte, ou les templates Angular — doivent continuer à tourner sur TypeScript 6.0 en attendant la version 7.1, qui doit combler ce manque. Ensuite, l’intégration éditeur est encore en rodage : VS Code passe par une extension dédiée en attendant un support natif, tandis que Visual Studio active TypeScript 7 automatiquement selon l’espace de travail.

Si votre projet touche à l’un de ces écosystèmes, jetez un œil à notre article sur la migration d’Astro 5 vers Astro 6 avant de faire le grand saut : mieux vaut vérifier la compatibilité de la chaîne d’outils avant de changer le compilateur sous ses pieds.

🎉 Conclusion

TypeScript 7.0 tient une promesse rare dans l’écosystème JS : un gain de performance massif sans rien casser côté sémantique. Pour un projet Node ou TypeScript pur — un NestJS ou un AdonisJS par exemple, deux frameworks qui vivent et respirent le typage strict — la migration se limite à ajuster deux ou trois options de configuration pour un gain de build à deux chiffres. Si votre stack dépend d’un outil basé sur Volar (Vue, Astro, Svelte), en revanche, patientez sur TypeScript 6.0 jusqu’à la 7.1 et son API programmatique. C’est aussi un signal de plus sur la tendance de fond de l’outillage JS : après Bun face à Node, c’est au tour du compilateur TypeScript de troquer le JavaScript pour un langage natif au nom de la vitesse.

🔗 Liens utiles

• Annonce officielle de TypeScript 7.0
• Annonce officielle de TypeScript 6.0 (la release “pont”)
• Dépôt microsoft/typescript-go
• Site officiel TypeScript