TypeScript 7.0 est sorti en version stable le 8 juillet 2026, après une bêta le 21 avril et une release candidate le 18 juin. La nouveauté n'est pas une fonctionnalité de langage : c'est le compilateur lui-même, réécrit en Go et livré sous le nom de code tsgo. Résultat annoncé par Microsoft : des builds de 8 à 12 fois plus rapides, avec un cas concret parlant — le build complet du code source de VS Code passe de 125,7 secondes sur TypeScript 6 à 10,6 secondes sur TypeScript 7, soit un facteur 11,9.

C'est le genre de gain qui change vraiment le quotidien : moins d'attente en CI, un tsc --noEmit qui ne casse plus le flux de pair programming, une intégration continue qui redescend sous la barre psychologique de la minute pour des monorepos qui tournaient à 10 minutes. Mais avant de basculer ton projet, il y a un point que beaucoup d'articles glissent sous le tapis : TypeScript 7.0 casse une partie de l'écosystème, et ce n'est pas un détail.

Cet article fait le point sur ce qui change réellement, ce qui ne fonctionne pas encore, et comment migrer sans surprise.

Un portage, pas une réécriture des règles

Premier point important à comprendre : tsgo n'est pas un nouveau compilateur avec ses propres règles de vérification de types. C'est un portage du compilateur historique (écrit en JavaScript) vers Go, pensé pour se comporter à l'identique de tsc sur du code TypeScript 5.x et 6.x. L'objectif de l'équipe était de supprimer la couche Node.js et de profiter du parallélisme natif de Go, pas de changer la sémantique du langage.

Concrètement, à partir de la version stable, l'installation ne change pas :

npm install -D typescript
npx tsc --noEmit

Avant la sortie officielle, le compilateur natif se testait via un paquet séparé, @typescript/native-preview, avec un binaire dédié :

npm install -D @typescript/native-preview
npx tsgo --noEmit

Ce paquet de preview reste utile si tu veux comparer les diagnostics entre l'ancien moteur JS et le nouveau moteur Go sur un projet existant, avant de basculer complètement.

Côté éditeur, le support progresse mais reste partiel : Visual Studio 2026 Insiders propose déjà une intégration expérimentale du compilateur natif pour la vérification de types en arrière-plan, ce qui se traduit par un IntelliSense nettement plus réactif sur les gros projets. Sur VS Code, le passage complet du serveur de langage (tsserver) au moteur Go n'est pas encore généralisé par défaut : c'est un chantier distinct de la sortie de tsc en version stable, et il vaut mieux ne pas confondre les deux calendriers.

Le vrai obstacle : l'absence d'API de compilation stable

Voici ce qui ne figure pas dans les titres accrocheurs sur les "10x" : TypeScript 7.0 ne fournit pas encore d'API programmatique stable équivalente à celle du compilateur JavaScript. Or c'est précisément cette API que des outils tiers utilisent pour parser et réécrire l'AST TypeScript.

Concrètement, si ton projet dépend de l'un de ces outils, tu vas avoir des ennuis en passant directement en TypeScript 7 :

typescript-eslint, utilisé par la quasi-totalité des configurations ESLint sur des projets TypeScript
@vue/compiler-sfc, pour la compilation des fichiers .vue
svelte-preprocess, pour Svelte
@angular/compiler-cli, pour Angular

Le mainteneur de typescript-eslint a documenté le problème dans l'issue de suivi du projet : sans API de compilation stable, le parseur ne peut pas s'appuyer sur TypeScript 7 pour produire l'arbre de syntaxe dont ESLint a besoin. Même logique côté Vue, Svelte et Angular, qui s'appuient tous sur les mêmes points d'entrée internes du compilateur pour leur tooling de build.

Le contournement officiel : faire cohabiter deux versions

Microsoft a anticipé le problème avec un paquet de compatibilité, @typescript/typescript6, qui fournit un binaire tsc6 correspondant à l'ancien compilateur JavaScript. L'idée : ton build principal tourne sur TypeScript 7 (rapide), pendant que les outils qui ont besoin de l'ancienne API programmatique continuent de s'appuyer sur TypeScript 6 en interne.

npm install -D typescript @typescript/typescript6

// package.json (extrait)
{
  "devDependencies": {
    "typescript": "^7.0.2",
    "@typescript/typescript6": "^6.9.0"
  }
}

La mécanique habituelle consiste à créer un alias de dépendance npm pour que l'outil concerné (ESLint, le compilateur Vue, etc.) résolve typescript vers le paquet de compatibilité plutôt que vers la version 7 installée à la racine :

// package.json — alias vers TypeScript 6 pour les outils qui en dépendent
{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.9.0"
  }
}

C'est une solution de transition, pas une architecture définitive. Microsoft a été clair sur ce point : le vrai correctif viendra avec TypeScript 7.1, dont la nouvelle API de compilation stable est attendue autour d'octobre 2026, dans la continuité du rythme de sortie habituel de trois à quatre mois entre versions mineures.

Migrer sans casser ta CI

Si ton projet est un candidat sérieux à la migration (pas de dépendance directe à Vue, Svelte, Angular ou à une grosse configuration typescript-eslint bloquante), voici la check-list à suivre avant de basculer.

1. Nettoyer le tsconfig.json

Certaines options historiques ne sont pas portées vers le compilateur Go, ou sont désormais découragées :

{
  "compilerOptions": {
    // À retirer : non porté vers tsgo
    "preserveConstEnums": false,

    // À remplacer selon ton contexte de build
    "moduleResolution": "bundler", // ou "nodenext" pour une lib Node
    // (au lieu de "node")

    // À supprimer : cibles et modules obsolètes
    // "target": "es5",
    // "downlevelIteration": true,
    // modules AMD / UMD / SystemJS
  }
}

Remplace aussi les chemins relatifs à baseUrl par des chemins relatifs à la racine du projet : le compilateur natif est plus strict sur la résolution de chemins.

2. Purger les artefacts de build incrémental

Les fichiers .tsbuildinfo générés par le compilateur JavaScript ne sont pas compatibles avec le format utilisé par le compilateur Go. Il faut les supprimer avant la première compilation en TypeScript 7, sous peine d'erreurs de cache incompréhensibles :

find . -name "*.tsbuildinfo" -not -path "*/node_modules/*" -delete

3. Comparer les diagnostics avant de basculer la CI

Sur une branche dédiée, lance le nouveau compilateur en parallèle de l'ancien et diffe la sortie :

npx tsc --noEmit > diagnostics-ts6.txt
npx tsc7 --noEmit > diagnostics-ts7.txt  # selon ton alias local
diff diagnostics-ts6.txt diagnostics-ts7.txt

L'objectif n'est pas de traquer des micro-différences de formatage de message, mais de repérer une éventuelle divergence de comportement sur ton code réel avant de l'imposer à toute l'équipe.

Faut-il migrer maintenant ?

La réponse dépend directement de ta stack :

Projet TypeScript "pur" (backend Node, librairie, monorepo sans framework à compilateur dédié) avec une configuration ESLint simple : les gains de vitesse sont immédiats et l'exposition au problème d'API est faible. Tu peux migrer dès maintenant, après le nettoyage du tsconfig.
Projet Vue, Svelte ou Angular, ou configuration typescript-eslint avancée (règles avec informations de type) : reste sur TypeScript 6 pour l'instant, ou utilise le contournement @typescript/typescript6 ciblé uniquement sur les outils bloquants, en gardant TypeScript 7 pour la compilation principale.
Équipe prudente : attends la sortie de TypeScript 7.1 et le retour de l'API de compilation stable, prévue autour d'octobre 2026, qui devrait débloquer la mise à jour de typescript-eslint et des tooling Vue/Svelte/Angular sans contournement.

Dans tous les cas, ne fais jamais ce changement un vendredi après-midi sur la branche principale. Teste sur une branche isolée, mesure le temps de build réel de ton projet (le gain varie selon la taille et la structure du code, pas seulement selon les benchmarks officiels), et vérifie que ta chaîne ESLint/CI ne dépend pas silencieusement de l'ancienne API avant de généraliser le changement.

Concrètement, cette semaine, tu peux : lister les dépendances de ton projet qui touchent au compilateur (typescript-eslint, plugins de framework, générateurs de types), lancer tsgo --noEmit ou tsc en version 7 sur une branche pour comparer les diagnostics, et noter la date de sortie de TypeScript 7.1 dans ton backlog si un de tes outils critiques est encore bloqué. C'est un changement d'infrastructure qui mérite d'être planifié, pas subi au prochain npm update.

TypeScript 7 est stable : ce qui casse avant de migrer