TypeScript 7.0 : le compilateur réécrit en Go, et le « 10× plus rapide » n’est pas du bluff

C’est officiel depuis le 8 juillet : TypeScript 7.0 est stable, et sous le capot ce n’est plus le même outil. Microsoft a réécrit l’intégralité du compilateur en Go — fini le compilateur écrit en TypeScript qui se compilait lui-même. Le gain annoncé : environ 10× plus rapide que la 6.0. Pour une annonce de tooling, c’est rare qu’un chiffre marketing tienne la route. Là, il tient.

Temps de check de types (gros projet) TS 6.0 ~60 s TS 7.0 ~6 s ≈ 10× plus rapide, même code
Temps de check de types sur un gros projet : TS 7.0 vs 6.0.

Ce qui change concrètement

Le nouveau compilateur natif exploite le code machine et le multithreading en mémoire partagée. En clair : les gros projets qui mettaient 30 à 60 secondes à typer passent sous la barre des quelques secondes.

CritèreTypeScript 6.0TypeScript 7.0
Langage du compilateurTypeScript (JS)Go (natif)
Vitesse de compilationréférence≈ 10× plus rapide
Parallélismelimitémultithreading mémoire partagée
Empreinte mémoireélevéeréduite (exec native)
Statutdernier build base JSstable (8 juil. 2026)

Pourquoi ça compte, vraiment

Le temps de compilation TypeScript, on a fini par s’y résigner. Sur les monorepos que je maintiens, le check de types était devenu le maillon lent du pré-commit : on le désactive « juste pour ce commit », puis on le désactive tout court, et on se retrouve avec des erreurs de types qui passent en prod.

Diviser le temps de check par dix, ce n’est pas un confort — c’est ce qui fait qu’on garde le garde-fou activé. Un feedback loop court, c’est un feedback loop qu’on utilise.

La migration depuis la 6.x

La 6.0, sortie le 23 mars, était présentée comme « la dernière basée sur le codebase JavaScript actuel » — le palier de transition. Le passage en 7.0 est pensé pour être quasi transparent côté langage, mais réécriture complète = comportements de bord possibles. Ma checklist :

  1. Bumper d’abord en 6.x et verrouiller (lockfile + CI verte).
  2. Passer en 7.0 sur une branche dédiée.
  3. Faire tourner la suite de tests plus le tsc --noEmit et le build de prod.
  4. Surveiller les plugins/transformers qui tapaient dans l’API interne de tsc — premiers suspects en cas de casse.

Ce que j’en retiens

C’est la mise à jour de tooling la plus tangible depuis longtemps. Pas une nouvelle syntaxe à apprendre, pas une mode : juste votre chaîne de build qui redevient rapide. À adopter, sans précipitation mais sans hésitation.

Pour aller plus loin

L’annonce et les notes de version officielles sont sur le blog TypeScript de Microsoft.

À lire aussi sur Mail Studio

En vidéo