Microsoft a publié TypeScript 7 en juillet 2026. Cette version conserve l’objectif et la sémantique de TypeScript, mais repose désormais sur une base native écrite en Go afin de profiter de l’exécution native, de la mémoire partagée et du parallélisme. Sur de gros projets testés par l’équipe TypeScript, les builds complets sont généralement entre 8 et 12 fois plus rapides que TypeScript 6.
Pourquoi réécrire le compilateur en Go ?
Le compilateur historique de TypeScript était lui-même écrit en TypeScript et exécuté sur JavaScript. Cette architecture avait un avantage évident : le projet utilisait son propre langage. Mais sur les très gros dépôts, les limites de performance du runtime et l’absence de mémoire partagée efficace entre workers rendaient difficile une accélération d’un ordre de grandeur.
Le port vers Go permet à TypeScript 7 d’utiliser du code natif et plusieurs threads avec une mémoire partagée. L’équipe indique avoir conservé autant que possible la structure et la logique du compilateur précédent pour limiter les écarts de comportement.
Des gains visibles dans les builds et dans l’éditeur
Les chiffres publiés donnent une bonne idée de l’échelle du changement. Sur les mesures de Microsoft, VS Code passe d’environ 125,7 secondes avec TypeScript 6 à 10,6 secondes avec TypeScript 7 pour un build complet. Sentry passe d’environ 139,8 secondes à 15,7 secondes et Playwright d’environ 12,8 secondes à 1,47 seconde.
L’amélioration concerne aussi le service de langage : chargement d’un projet, diagnostics, autocomplétion, recherche de références et mode --watch. Sur le code de VS Code, l’équipe TypeScript mesure un passage d’environ 17,5 secondes à moins de 1,3 seconde avant l’apparition de la première erreur dans l’éditeur.
Le gain le plus important n’est pas toujours le build final
Sur un projet moyen, gagner quelques secondes en CI est utile. Mais réduire la latence de l’éditeur et du type-check pendant toute la journée change surtout la boucle de feedback du développeur : moins d’attente entre une modification et son diagnostic.
TypeScript devient réellement multithread
TypeScript 7 parallélise plusieurs étapes, notamment l’analyse des fichiers, une partie du type-checking et l’émission. Par défaut, le compilateur utilise plusieurs workers de vérification. Les nouveaux paramètres expérimentaux --checkers et --builders permettent d’ajuster le parallélisme pour les gros projets ou les monorepos.
Plus de parallélisme ne signifie toutefois pas automatiquement plus de vitesse. Sur un runner CI avec peu de CPU ou de mémoire, augmenter le nombre de workers peut être contre-productif. TypeScript propose donc également --singleThreaded pour forcer un fonctionnement mono-thread, utile pour le diagnostic ou les environnements contraints.
Le point à surveiller : la compatibilité des outils
TypeScript 7.0 ne fournit pas encore d’API de compilateur compatible avec celle des versions précédentes. C’est important pour les outils qui importent directement l’API TypeScript, par exemple certains linters, générateurs ou plugins. Microsoft prévoit une nouvelle API avec TypeScript 7.1.
Pour faciliter la transition, le paquet @typescript/typescript6 permet de conserver TypeScript 6 et son API en parallèle. Une équipe peut donc utiliser le nouveau tsc pour le build tout en gardant TypeScript 6 pour un outil qui n’est pas encore compatible.
Les nouveaux défauts peuvent aussi casser une migration
TypeScript 7 reprend les nouveaux comportements introduits avec TypeScript 6. Parmi les changements importants : strict est activé par défaut, module utilise esnext, types est vide par défaut et rootDir peut nécessiter une configuration explicite. Plusieurs anciennes options sont désormais des erreurs, comme target: es5, moduleResolution: node ou baseUrl.
Pour un projet déjà proprement configuré avec un tsconfig.json explicite, la transition peut être très simple. Pour un projet ancien qui dépend encore de valeurs implicites ou d’options dépréciées, il vaut mieux passer d’abord par TypeScript 6 et corriger les avertissements avant de tester TypeScript 7.
Une migration prudente en cinq étapes
- mesurer le temps actuel de
tsc --noEmitet des builds CI pour disposer d’un point de comparaison ; - mettre le projet en conformité avec TypeScript 6 et supprimer les options dépréciées ;
- tester TypeScript 7 sur une branche en lançant le type-check, les tests et le build de production ;
- vérifier les outils qui utilisent directement l’API TypeScript, en particulier ESLint, plugins et générateurs ;
- mesurer CPU, mémoire et durée en CI avant d’ajuster éventuellement
--checkersou--builders.
Faut-il migrer maintenant ?
Pour un projet TypeScript actif dont la chaîne d’outils est compatible, TypeScript 7 mérite clairement un test : les gains annoncés concernent précisément les opérations répétitives qui ralentissent les grosses bases de code. Pour un projet stable avec beaucoup de tooling dépendant de l’API du compilateur, attendre TypeScript 7.1 peut être plus confortable.
La bonne décision n’est donc pas « TypeScript 7 est plus rapide, on migre ». C’est plutôt : mesurer le coût actuel du type-check, vérifier les dépendances de tooling, tester la compatibilité sur une branche et comparer des chiffres réels sur son propre projet.
Sources
Publié le 9 septembre 2026. Les comportements et performances cités correspondent aux mesures et documentations publiées par l’équipe TypeScript.