Outils

Le 8 juillet 2026, Microsoft a publié TypeScript 7.0, la première version stable bâtie sur un compilateur écrit en Go plutôt qu'en JavaScript. C'est le plus grand changement de l'histoire du langage : le vérificateur de types et le compilateur dont dépendent des millions de projets tournent désormais en code natif, et les benchmarks publiés par Microsoft situent les builds complètes environ 8 à 12 fois plus rapides que la version précédente.

Le projet a une longue trajectoire. Microsoft l'a annoncé en mars 2025 sous le nom de code Project Corsa, désignant la base de code existante en JavaScript sous le nom de Strada. Une bêta est arrivée en avril 2026, une release candidate le 18 juin 2026, et la version 7.0 en disponibilité générale le 8 juillet 2026. L'annonce phare est restée la même tout du long : une accélération d'environ dix fois de la vérification de types et de la compilation.

Les chiffres publiés par Microsoft sont concrets. Compiler la base de code de Visual Studio Code est passé d'environ 77.8 secondes à 7.5 secondes, soit une amélioration de 10.4x, et Playwright est tombé de 11.1 secondes à 1.1 secondes. Les projets réels varieront, mais le schéma sur l'ensemble des benchmarks de Microsoft se regroupe autour du facteur dix.

Deux choses expliquent cette vitesse. Environ la moitié vient du fait de s'exécuter en code natif compilé au lieu de JavaScript exécuté par Node. L'autre moitié vient de la concurrence à mémoire partagée : l'implémentation en Go peut répartir le travail de vérification de types sur plusieurs cœurs de CPU en utilisant de la mémoire partagée, ce que la version JavaScript mono-thread ne pouvait pas faire proprement.

Point important, il s'agit d'un portage, pas d'une réécriture. Microsoft a traduit la logique du compilateur existant en Go tout en préservant le même comportement de vérification de types, si bien que l'objectif est que votre code soit vérifié à l'identique, avec les mêmes erreurs aux mêmes endroits, mais bien plus vite. L'équipe a expliqué que Go a été choisi en partie parce que sa syntaxe et sa structure correspondent de près au code JavaScript existant, ce qui a rendu un portage fidèle réalisable aussi bien pour les humains que pour les outils.

Au quotidien, le bénéfice se ressent à deux endroits. Les éditeurs deviennent plus réactifs sur les grandes bases de code, car le service de langage derrière des fonctions comme l'autocomplétion, l'aller à la définition et le soulignement des erreurs effectue le même travail en une fraction du temps. Et les pipelines d'intégration continue qui exécutent le compilateur à chaque commit raccourcissent, ce qui compte surtout pour les grands monorepos où la vérification de types était devenue un vrai goulot d'étranglement.

Si vous envisagez de l'adopter, traitez le passage comme une vérification de compatibilité plutôt que comme une réécriture de votre propre code. Comme la sémantique est préservée, la plupart des projets ne devraient voir aucun changement dans les erreurs remontées. Vérifiez tout de même sur votre build réelle : assurez-vous que vos options tsconfig, vos scripts de build et tout outillage personnalisé qui se branche sur l'API TypeScript se comportent comme prévu. Consultez les notes de version officielles pour connaître le chemin d'activation exact et les éventuelles réserves documentées avant de basculer un pipeline de production.

Cette sortie s'inscrit aussi dans une tendance plus large. La chaîne d'outils JavaScript a passé plusieurs années à déplacer les outils critiques pour la performance vers des langages natifs : des bundlers et transpileurs écrits en Go et en Rust, comme esbuild et la famille SWC et Biome, ont installé l'attente que l'outillage de base soit quasi instantané. Le vérificateur de types de TypeScript restait l'une des dernières grosses pièces à tourner encore en JavaScript, et TypeScript 7.0 comble cet écart.

En résumé : TypeScript 7.0 ne change pas la façon dont vous écrivez du TypeScript, mais il change ce que l'on ressent à l'utiliser à grande échelle. Si des vérifications de types lentes ou des performances d'éditeur poussives étaient devenues un impôt sur un gros projet, cette version vise précisément ce point de douleur, et les accélérations mesurées sont assez importantes pour valoir la peine de planifier une migration autour d'elles.