TypeScript 7 réécrit en Go : le compilateur natif, 8 à 12 fois plus rapide

Un pipeline d'intégration continue qui met plusieurs minutes à vérifier les types, un éditeur qui rame dès qu'un gros projet TypeScript dépasse le million de lignes : ces frictions du quotidien ont désormais une réponse. Le 8 juillet 2026, l'équipe TypeScript de Microsoft a publié la version stable de TypeScript 7.0 (7.0.2), une version dont le compilateur, le service de langage et l'outillage sont entièrement réécrits en Go. À la clé, une vérification de types et une compilation généralement 8 à 12 fois plus rapides sur un build complet, et un éditeur nettement plus réactif.

Cette bascule ne tombe pas du ciel : elle se prépare depuis mars 2025, et une version intermédiaire, TypeScript 6.0, a servi de pont pour éviter la rupture brutale. Après une bêta en avril et une release candidate en juin, la version stable est maintenant là. Voici ce qui change concrètement, pourquoi Go a été choisi, et ce que les équipes doivent anticiper avant de migrer.

Ce qui vient de sortir : TypeScript 7.0 en version stable

TypeScript 7.0 est la version dite « native » : le compilateur, le service de langage utilisé par les éditeurs et l'outillage associé quittent la base historique écrite en JavaScript pour une implémentation en Go. C'est la même logique de vérification de types et de génération de code, mais exécutée par un binaire compilé nativement plutôt que par un programme JavaScript tournant sur Node.js.

L'installation se fait comme n'importe quelle autre version, via npm install -D typescript : vous récupérez directement le nouvel exécutable tsc, sans changer vos scripts. Un point qui prêtait à confusion pendant la phase de préversion : les paquets nightly étaient publiés sous @typescript/native-preview (plus de 8,5 millions de téléchargements hebdomadaires) et exposaient le binaire sous le nom tsgo. Désormais, les builds nightly reprennent progressivement sous le paquet standard typescript via le tag next (npm install -D typescript@next).

Pourquoi 8 à 12 fois plus rapide

Les chiffres viennent des mesures publiées par Microsoft sur des bases de code open source. Sur le dépôt de VS Code (environ 2,3 millions de lignes de TypeScript), le build passe de 125,7 secondes à 10,6 secondes, soit un facteur d'environ 11,9. Sur Sentry, on tombe de 139,8 à 15,7 secondes (8,9×), sur Bluesky de 24,3 à 2,8 secondes (8,7×), sur Playwright de 12,8 à 1,47 seconde (8,7×) et sur tldraw de 11,2 à 1,46 seconde (7,7×). En dédiant plus de cœurs au type-checking (--checkers 8), VS Code descend même à 7,5 secondes, soit un facteur proche de 16,7 sur cette machine.

Le gain ne se limite pas à la ligne de commande. Ouvrir un fichier comportant une erreur dans le dépôt VS Code prenait auparavant environ 17,5 secondes entre l'ouverture de l'éditeur et l'affichage de la première erreur ; avec TypeScript 7, c'est moins de 1,3 seconde, soit plus de 13 fois plus vite. Côté mémoire, le compilateur natif demande généralement moins de ressources sur l'ensemble d'un build : de -6 % à -26 % selon les projets mesurés. Enfin, Microsoft indique que le nouveau service de langage réduit de plus de 80 % les commandes qui échouent et de plus de 60 % les plantages du serveur par rapport à TypeScript 6.0 : autocomplétion, aperçu rapide, aller à la définition et recherche de références deviennent plus fiables sur les gros projets.

Concrètement, deux postes en profitent directement. Côté intégration continue, plusieurs équipes rapportent des gains spectaculaires : chez Slack, la vérification de types en CI est passée d'environ 7,5 minutes à 1,25 minute et 40 % du temps de merge queue a été éliminé, tandis que l'équipe News Services de Microsoft dit économiser 400 heures d'attente de build par mois et que Vanta observe jusqu'à 9× de gain sur l'un de ses plus gros projets. Côté poste de travail, l'éditeur cesse de décrocher sur les gros dépôts : les développeurs de Canva voient la première erreur s'afficher en environ 4,8 secondes contre 58 auparavant. Le confort de développement au quotidien remonte nettement.

Pourquoi Go, et pas Rust ou C#

La question revient systématiquement dans les équipes techniques. Ryan Cavanaugh, lead développeur de TypeScript, l'a détaillée dans une discussion officielle sur le dépôt du projet. Go a été retenu parce qu'il permet un code structurellement proche de la base TypeScript existante, offre une gestion mémoire automatique sans forcer tout le code à gérer l'allocation à la main, et excelle sur le parcours de graphes, avec des nœuds polymorphes reliés par des pointeurs ascendants et descendants. Or c'est exactement ce que fait un compilateur : parcourir en tous sens un arbre de syntaxe.

L'alternative, une réécriture complète en Rust, aurait pu prendre plusieurs années et risquait de produire une version incompatible, inutilisable en pratique. C'est l'arbitrage que rapporte le média spécialisé InfoQ, citant Ryan Cavanaugh : plutôt que cette réécriture de zéro, le portage en Go donnait un résultat utilisable en un an environ tout en restant très proche de l'existant. Ce chantier, connu sous le nom de code « Corsa » (par opposition à l'ancienne base surnommée « Strada »), a été annoncé officiellement le 11 mars 2025 : la version stable n'est donc pas un coup d'éclat, mais l'aboutissement d'un projet mené sur plus d'un an.

TypeScript 6.0, la version pont

Microsoft présente TypeScript 6.0, sorti le 23 mars 2026, comme le « pont entre TypeScript 5.9 et 7.0 ». Il reste écrit en JavaScript, mais aligne autant que possible ses valeurs par défaut et son comportement sur ceux du futur compilateur natif, pour limiter les surprises au moment de la bascule. Dans l'annonce de la release candidate, l'éditeur encourage d'ailleurs explicitement les équipes à adopter TypeScript 6.0 pour rendre la transition vers 7.0 plus douce.

Un exemple parlant : TypeScript 6.0 introduit le drapeau --stableTypeOrdering, qui aligne le tri des types sur le comportement de la version 7, au prix d'un ralentissement pouvant aller jusqu'à 25 % en 6.0. Dans TypeScript 7, ce comportement devient la valeur par défaut et ne peut plus être désactivé. La mécanique du pont est là tout entière : une option de compatibilité aujourd'hui, une norme figée demain.

TypeScript 6.0 n'est pas qu'un sas de compatibilité. La version apporte aussi de vraies nouveautés de langage, indépendantes du chantier Go : le support du type Temporal désormais officiellement partie de JavaScript, les méthodes getOrInsert et getOrInsertComputed sur Map, la fonction RegExp.escape, une cible de compilation es2025, et une meilleure inférence de type pour certaines fonctions.

Ce qui casse en 7.0 : les breaking changes à anticiper

C'est le cœur du sujet pour qui maintient une base existante. Les options que TypeScript 6.0 se contente de déprécier deviennent des erreurs dures en 7.0. Parmi les principales : --target es5, --downlevelIteration, --moduleResolution node/node10 ou classic, les modules amd, umd et systemjs, --baseUrl, --esModuleInterop ou --allowSyntheticDefaultImports à false, le mot-clé module dans les namespaces, le mot-clé asserts sur les imports (remplacé par with), et la directive no-default-lib. Un tsconfig.json hérité d'un projet ancien risque donc de ne plus compiler tel quel.

Le piège moins évident tient aux nouvelles valeurs par défaut. En 7.0, strict passe à true, module à esnext, target à la dernière version stable d'ECMAScript précédant esnext, types à un tableau vide (il faut désormais lister explicitement les types globaux à inclure, ou remettre ["*"] pour l'ancien comportement), rootDir au dossier courant, noUncheckedSideEffectImports à true, libReplacement à false, et stableTypeOrdering est activé sans possibilité de le désactiver. À noter aussi qu'alwaysStrict est considéré comme true et ne peut plus être désactivé. Un build peut donc casser même sans utiliser une seule option explicitement dépréciée, simplement parce qu'un défaut a changé — Microsoft signale que les changements sur rootDir et types sont les plus susceptibles de surprendre. À noter aussi un vrai changement de sémantique du langage : les types littéraux de gabarit préservent désormais les points de code Unicode complets, un emoji étant traité comme une seule unité plutôt que découpé en deux.

Pour amortir le choc, Microsoft fournit un paquet de compatibilité, @typescript/typescript6, qui expose un binaire tsc6 et réexporte l'API de la 6.0. Il permet de faire tourner TypeScript 6.0 en parallèle de 7.0 sans conflit de nom (via des alias npm), le temps de migrer progressivement un monorepo ou plusieurs projets.

Un point de vigilance majeur, confirmé par l'annonce stable : les frameworks qui embarquent TypeScript dans leur propre compilateur ne peuvent pas encore basculer sur la version native. Concrètement, les workflows Vue, Angular, Svelte, Astro ou MDX (via des outils comme Volar) doivent continuer d'utiliser TypeScript 6.0 pour le moment, car TypeScript 7.0 n'expose pas encore d'API programmatique stable. Un projet Angular peut par exemple combiner TypeScript 7 en ligne de commande, pour une détection d'erreurs rapide avec tsc, et TypeScript 6.0 pour l'expérience éditeur. Microsoft présente cela comme un point-en-temps qui sera résolu avec l'arrivée de la nouvelle API.

Parallélisation et watch : l'impact sur la CI et le dev local

TypeScript 7 introduit une parallélisation pilotable en ligne de commande, via des drapeaux encore marqués comme expérimentaux. --checkers répartit la vérification de type sur plusieurs workers (quatre par défaut, mais monter à 8 accélère encore les gros dépôts au prix de plus de mémoire), --builders parallélise la construction des références de projet sous --build, et --singleThreaded repasse tout en mono-thread pour le débogage, la comparaison avec la 6.0 ou les environnements contraints comme certains runners de CI à faibles ressources. Attention à l'effet multiplicatif : --checkers 4 --builders 4 autorise jusqu'à 16 type-checkers simultanés, ce qui peut être excessif. Ces réglages agissent directement sur le temps de build et la mémoire consommée par les runners partagés.

Le mode --watch a été entièrement reconstruit sur la base du watcher du bundler Parcel (porté de C++ vers Go), avec une consommation de ressources nettement réduite sur les projets à grand nombre de dépendances dans node_modules. Enfin, le service de langage s'appuie sur le Language Server Protocol standard, ce qui ouvre le nouveau serveur à la plupart des éditeurs modernes, pas seulement VS Code. Pour ce dernier, une extension dédiée « TypeScript 7 » devient l'expérience par défaut une fois installée (le support sera intégré directement à VS Code dans les semaines qui suivent la sortie), et Visual Studio active automatiquement TypeScript 7 selon le workspace.

Ce que les équipes doivent faire maintenant

La trajectoire est désormais complète : TypeScript 7.0 Beta est sorti le 21 avril 2026, la release candidate le 18 juin, et la version stable (7.0.2) le 8 juillet 2026. Un point de vigilance mérite toutefois d'être noté pour les auteurs d'outils : TypeScript 7.0 ne ship pas encore d'API programmatique stable, celle dont dépendent les plugins et l'outillage tiers (typescript-eslint, Volar, etc.). Une nouvelle API — différente de l'ancienne — est attendue avec TypeScript 7.1. L'usage en ligne de commande et dans l'éditeur est donc pleinement disponible, mais la compatibilité complète de l'écosystème de plugins arrivera un peu plus tard. Microsoft annonce ensuite un retour à un rythme classique, avec de nouvelles versions tous les trois à quatre mois.

La marche à suivre raisonnable tient en peu de mots : adopter TypeScript 6.0 d'abord, corriger les options dépréciées qu'il signale, puis viser 7.0 une fois la base assainie. Pour un projet ancien dont le tsconfig.json traîne des réglages d'une autre époque, ce nettoyage rejoint un travail de maintenance plus large, souvent l'occasion de remettre à plat des choix qui n'ont plus lieu d'être.

Chez Koul, on suit ces évolutions de près pour les stacks qu'on développe et qu'on reprend, de Next.js aux applications métier entièrement écrites en TypeScript. Décider du bon moment pour migrer, mesurer l'effort réel sur un tsconfig hérité, préparer la CI et le poste des développeurs : ce genre d'arbitrage se pose mieux dans le cadre d'un audit et étude de cadrage, où chaque choix technique est évalué à l'aune du projet réel plutôt que de l'enthousiasme d'une release note. Notre équipe pluridisciplinaire accompagne ce type de transition, du diagnostic au plan de migration progressive.

Pour aller plus loin

• TypeScript chez Koul : notre approche du typage strict pour des applications robustes et maintenables.
• Développement React : une stack largement typée en TypeScript, directement concernée par les gains d'éditeur.
• React 19 : les grandes nouveautés de la bibliothèque JavaScript : les évolutions récentes de la bibliothèque côté typage et rendu.
• Next.js 15 : le framework React et ses nouveautés, un terrain typé de bout en bout.
• Cloud et DevOps : pipelines d'intégration continue et temps de build, là où le compilateur natif pèse le plus.

Sources

Actualité vérifiée sur les annonces officielles de l'équipe TypeScript et une source de presse spécialisée indépendante :

• Announcing TypeScript 7.0, la version stable (équipe TypeScript, Microsoft, 8 juillet 2026)
• Announcing TypeScript 7.0 RC (équipe TypeScript, Microsoft, 18 juin 2026)
• A 10x Faster TypeScript, annonce du portage natif en Go (Microsoft, 11 mars 2025)
• Announcing TypeScript 6.0, la version pont (Microsoft, 23 mars 2026)
• Announcing TypeScript 7.0 Beta (Microsoft, 21 avril 2026)
• Why Go?, discussion de Ryan Cavanaugh sur le dépôt microsoft/typescript-go
• Microsoft Announces Native TypeScript Compiler Port for 10X Performance Boost (InfoQ, mai 2025)