Actu

TypeScript 7.0 est sorti le 8 juillet 2026, et le titre tient en une phrase : le compilateur est désormais écrit en Go et non plus en TypeScript lui-même, et il compile environ 10 fois plus vite. Pour quiconque maintient un gros projet Vue, Nuxt ou React, c'est le plus grand changement du quotidien TypeScript depuis des années : pas une nouvelle syntaxe, mais un nouveau moteur derrière la même commande tsc.

Rien ne change dans votre façon d'écrire des types. Vos fichiers .ts, votre tsconfig.json et vos erreurs de type restent identiques. Ce qui change, c'est la vitesse à laquelle le compilateur analyse, vérifie et génère votre projet, et la réactivité de votre éditeur pendant que vous travaillez. Ce guide couvre ce qui change vraiment, les vrais chiffres des benchmarks, comment l'essayer aujourd'hui et les compromis honnêtes avant de migrer.

Ce qui change vraiment

Le projet, nom de code Corsa, est un portage plutôt qu'une réécriture. L'équipe de Microsoft, menée par l'architecte principal de TypeScript Anders Hejlsberg, a transposé en Go les algorithmes et structures de données existants pour que le comportement de vérification de types reste identique : la même inférence, les mêmes erreurs. Go a été préféré à Rust surtout parce que les arbres syntaxiques et les tables de symboles de TypeScript reposent sur des références cycliques, qui s'accordent bien mieux avec le ramasse-miettes et les goroutines de Go qu'avec les règles de possession de Rust.

La vitesse vient de deux choses. Le code natif compilé est tout simplement plus rapide que l'ancien compilateur écrit en JavaScript, et le nouveau compilateur travaille en parallèle : l'analyse, la vérification de types et la génération peuvent s'exécuter sur plusieurs threads au lieu d'un seul. La consommation mémoire baisse d'environ moitié par rapport au compilateur JavaScript, et le service de langage de l'éditeur charge les gros projets bien plus vite.

La vitesse, en vrais chiffres

Microsoft a publié des chiffres avant/après sur de vrais projets. Compiler la base de code de VS Code (environ 1,5 million de lignes) est passé de 77,8 secondes à 7,5 secondes, soit un gain de 10,4x. Playwright a compilé environ 10x plus vite et TypeORM environ 13,5x. Ce sont des compilations complètes, celles qui pèsent le plus sur le temps de CI et ralentissent les vérifications de types en local sur les gros dépôts.

• TypeScript 7.0 (sorti le 8 juillet 2026) remplace le compilateur écrit en JavaScript par un portage natif écrit en Go : mêmes types, nouveau moteur
• Builds complets environ 10x plus rapides (VS Code 77,8s à 7,5s), chargement de projet dans l'éditeur environ 8x plus rapide et environ 50% de mémoire en moins
• C'est un portage (nom de code Corsa) mené par Anders Hejlsberg : comportement de vérification de types identique, désormais parallélisé sur plusieurs threads
• S'installe et s'exécute sous le nom tsc ; les préversions nocturnes gardent le nom tsgo sous @typescript/native-preview
• Changements cassants : cible es5, mode de résolution node, baseUrl et AMD/UMD/SystemJS supprimés ; certaines valeurs par défaut (rootDir, types) changent
• Les outils sur l'API programmatique (typescript-eslint, ts-morph, transformateurs) attendent une version 7.x ultérieure : adoptez côte à côte pour l'instant

Les gains dans l'éditeur comptent tout autant au quotidien. Charger un gros projet dans le service de langage est passé d'environ 9,6 secondes à 1,2 seconde, soit environ 8x. C'est la différence entre attendre que l'auto-complétion se réveille et voir l'auto-complétion, le aller-à-la-définition et le soulignement des erreurs répondre presque instantanément sur un projet qui semblait lent.

Comment l'essayer aujourd'hui

L'installation est volontairement banale : le compilateur natif s'installe depuis le paquet habituel et s'exécute sous le nom tsc, donc la plupart des projets peuvent l'essayer avec une seule mise à jour de dépendance. Les préversions précédentes livraient un binaire tsgo séparé, et les builds nocturnes sont encore publiés sous @typescript/native-preview avec ce nom, mais la version stable, elle, s'appelle simplement tsc. De nouveaux drapeaux permettent de régler le parallélisme, par exemple le nombre de workers de vérification, ou de le désactiver via un mode mono-thread quand vous avez besoin d'une sortie sérielle reproductible.

Une façon sûre de l'adopter est de le faire côte à côte. Vous pouvez garder le compilateur 6.x précédent installé sous un alias (souvent appelé tsc6) tout en pointant votre build principal vers la 7.0. Cela vous laisse utiliser le nouveau compilateur rapide pour les builds et l'édition, pendant que tout outil qui dépend encore de l'ancienne API programmatique stable continue de fonctionner sans y toucher.

Les changements cassants à surveiller

Il y a de vrais changements cassants, alors lisez les notes de version avant de migrer sur place. Plusieurs options dépréciées de longue date disparaissent, dont la cible es5, l'ancien mode de résolution de modules node, baseUrl, et les formats de modules AMD, UMD et SystemJS. Certaines valeurs par défaut changent aussi, comme rootDir et l'ensemble par défaut des paquets de types ambiants, ce qui peut faire apparaître de nouvelles erreurs dans des configs qui s'appuyaient sur l'ancien comportement implicite.

Les compromis honnêtes

Le gain de vitesse est réel, mais l'écosystème a besoin d'un temps d'adaptation. Les outils bâtis sur l'API programmatique de TypeScript (typescript-eslint, ts-morph, transformateurs de compilateur personnalisés) dépendent d'interfaces qui ne doivent se stabiliser que dans une version 7.x ultérieure. En attendant, les équipes qui s'appuient beaucoup sur ces outils voudront sans doute utiliser la 7.0 pour les builds et l'édition tout en gardant la lignée 6.x disponible pour les parties de la chaîne d'outils qui ne sont pas encore prêtes.

Il faut aussi garder des attentes réalistes : TypeScript 7 rend le compilateur plus rapide, pas votre application livrée. La sortie reste le même JavaScript qui tourne dans les mêmes navigateurs et versions de Node, donc les performances à l'exécution ne changent pas. Ce que vous gagnez, ce sont des temps de build et de CI plus courts et un éditeur plus vif, ce qui, sur un gros projet front-end, correspond exactement à l'endroit où était la friction. Pour la plupart des équipes Vue, Nuxt et React, le geste pratique est de l'essayer sur une branche, de guetter les options supprimées, et de l'adopter pour le build et l'éditeur une fois les chiffres vérifiés.