TypeScript 7.0 est 10x plus rapide et écrit en Go. Voici comment l'adopter sans casser votre CI.

Microsoft a publié le Release Candidate de TypeScript 7.0 le 18 juin 2026, et la nouveauté principale n'est pas un nouveau morceau de syntaxe. C'est le compilateur lui-même. Au cours de l'année écoulée, l'équipe a porté TypeScript depuis son propre code source en JavaScript vers Go, et le résultat effectue la vérification des types environ 10 fois plus vite que TypeScript 6.0. Les chiffres publiés sont sans appel : la base de code de VS Code, environ 1,5 million de lignes, passe d'une vérification de 77,8 secondes à 7,5 secondes. Sentry passe de 133 secondes à 16. Le démarrage de l'éditeur tombe d'environ 9,6 secondes à 1,2, et la consommation mémoire est réduite de moitié.

Deux détails comptent plus que la vitesse brute. D'abord, il s'agit d'un portage, pas d'une réécriture complète. L'équipe a transposé la logique de vérification des types existante vers Go en conservant la sémantique, donc 7.0 devrait appliquer les mêmes règles que votre code satisfait déjà sous 6.0. Ensuite, vous l'installez comme n'importe quelle autre version, directement depuis le package typescript sur npm. Une version stable est prévue dans environ un mois, et les régressions sont à signaler dans le dépôt microsoft/typescript-go plutôt que dans le dépôt principal de TypeScript.

Alors, qu'est-ce qu'un compilateur 10 fois plus rapide apporte concrètement à une équipe ? Plus qu'il n'y paraît au premier abord.

Le gain n'est pas sur votre ordinateur, c'est la CI

Un éditeur plus rapide, c'est agréable. Une CI plus rapide change la façon dont les gens travaillent. Quand nous développons des applications cloud-natives pour des clients entreprises en PHP et Docker, la vérification des types est généralement l'une des étapes les plus lentes du pipeline, et elle se trouve sur le chemin critique de chaque merge. Réduire une vérification de deux minutes à quinze secondes ne fait pas que gagner deux minutes. Ça change les comportements. Les développeurs arrêtent de regrouper les changements pour éviter le pipeline lent, les reviewers obtiennent un check vert pendant que le contexte est encore frais, et l'habitude « je merge et je surveille la CI » qui casse silencieusement la branche principale commence à disparaître.

Nous avons vu des équipes s'adapter à des outils lents sans s'en rendre compte : des pull requests gigantesques, des vérifications locales ignorées, un réflexe --no-verify à chaque commit. La plupart de ces comportements sont une réponse à un feedback trop long. Supprimez l'attente et beaucoup de ces habitudes perdent leur raison d'être.

Un compilateur plus rapide reste un changement de dépendance

Voici ce qui se perd dans l'enthousiasme. Remplacer votre compilateur par un binaire écrit dans un autre langage est une décision de chaîne d'approvisionnement, pas un gain gratuit. Lors de nos travaux de pentesting et d'audit de sécurité, la chaîne d'outils de build est l'un des premiers endroits où nous regardons, car elle s'exécute avec un accès complet à votre code source et souvent à vos secrets, sur chaque machine de développeur et chaque runner CI. Un nouveau tsc est exactement ce type de composant.

Rien de tout cela ne signifie que le RC est risqué à essayer. Microsoft l'utilise sur des bases de code de plusieurs millions de lignes en interne et en externe depuis plus d'un an. Cela signifie que vous devriez l'adopter délibérément : épinglez la version exacte, lisez le changelog avant de le mettre à jour, et ne laissez pas un développeur remplacer silencieusement le compilateur pour toute l'équipe un vendredi après-midi.

Que faire cette semaine

Ne faites pas encore de 7.0 votre vérification CI bloquante. Ajoutez-la à côté de celle que vous avez déjà. La plupart des systèmes CI vous permettent d'exécuter un second job qui compile avec typescript@rc et rapporte son résultat sans bloquer le merge. Exécutez les deux pendant quelques semaines, comparez les erreurs, et vous saurez exactement où 7.0 diverge de votre build actuel avant que ça compte. Comme il s'agit d'un portage plutôt que d'une réécriture, la plupart des équipes constatent que la différence est vide, mais les quelques-unes qui tombent sur un cas limite voudront le trouver à leur propre rythme, et non lors d'une mise à jour précipitée après la sortie de la version stable.

Ce modèle n'est pas spécifique à TypeScript. Nous utilisons la même approche fantôme dans notre travail web et mobile chaque fois qu'un outil central publie une version majeure. Nous préparons une mise à jour d'Xcode ou du plugin Android Gradle de la même manière dans nos projets iOS et Android natifs, dans un job parallèle, bien avant qu'elle touche la machine de tout le monde. Les équipes qui se font avoir sont généralement celles qui lisent « les tests passent encore » comme preuve que rien n'a changé. Si vous voulez voir comment nous procédons en pratique, notre travail de développement est construit autour exactement de ce type de mise à jour progressive et sans stress.

Si un pipeline lent que votre équipe a silencieusement appris à contourner vous semble familier, parlons-en.