TypeScript 7 vient de sortir officiellement, et c’est probablement la version la plus structurante depuis la création du langage. Si vous gérez des projets TypeScript à grande échelle, vous allez vouloir comprendre ce qui change et ce que ça implique en pratique.
TypeScript 7 : une réécriture complète, pas une mise à jour
Le 8 juillet 2026, Microsoft a annoncé TypeScript 7.0. Derrière ce numéro de version se cache une décision radicale : le compilateur et le serveur de langage ont été entièrement réécrits en Go. Ce n’est pas un patch de performance, c’est un changement d’architecture fondamental.
Le choix de Go est notable. Dans l’écosystème des outils de build, Rust est souvent la référence pour la performance native. Microsoft a préféré Go, un langage déjà utilisé par esbuild pour des raisons similaires. Le résultat annoncé : des gains entre 8x et 12x sur les builds complets, grâce au code natif, à la mémoire partagée et au multithreading.
Des chiffres mesurés sur des projets réels
L’annonce ne repose pas sur des benchmarks artificiels. Microsoft a publié des données issues de projets open source connus.
Voici les temps de build comparés entre TypeScript 6 et TypeScript 7 :
- VS Code : 125,7s contre 10,6s, soit 11,9x plus rapide
- Sentry : 139,8s contre 15,7s, soit 8,9x plus rapide
- Bluesky : 24,3s contre 2,8s, soit 8,7x plus rapide
- Playwright : 12,8s contre 1,47s, soit 8,7x plus rapide
La consommation mémoire baisse aussi. Bluesky passe de 1,8 Go à 1,3 Go (-26 %). VS Code descend de 5,2 Go à 4,2 Go (-18 %). Ce ne sont pas des gains anecdotiques.
Dans l’éditeur, l’impact est encore plus frappant. Sur la base de code VS Code, le temps entre l’ouverture d’un fichier et l’affichage de la première erreur est passé de 17,5 secondes à moins de 1,3 seconde.
Parallélisation native : le vrai moteur des gains
TypeScript 7 parallélise plusieurs étapes du build : le parsing, la vérification de types et l’émission. Ce n’est pas juste du multithreading ajouté en surface, c’est une refonte de la chaîne de compilation.
Deux nouveaux flags permettent de contrôler ce comportement :
--checkers: nombre de workers de vérification de types (défaut : 4)--builders: nombre de builders parallèles pour les références de projets--singleThreaded: désactive toute parallélisation, utile pour le débogage ou les environnements contraints
Avec --checkers 8, VS Code passe à 7,51s pour un gain de 16,7x. Les gains dépendent du nombre de coeurs disponibles. En CI avec peu de ressources, réduire ce paramètre peut s’avérer plus efficace.
Cohabitation TypeScript 7 et TypeScript 6 : comment ça marche
TypeScript 7.0 ne livre pas encore d’API publique. Celle-ci est prévue pour TypeScript 7.1. En attendant, Microsoft a publié un package de compatibilité : @typescript/typescript6. Il fournit un exécutable tsc6 et réexporte l’API TypeScript 6.0, ce qui permet à des outils comme typescript-eslint de continuer à fonctionner sans modification.
La configuration recommandée dans package.json :
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
Cette cohabitation est volontaire et documentée. Elle répond à un besoin réel : certains outils dépendent encore de l’API TypeScript 6. Ce n’est pas un signe de fragilité, c’est une stratégie de transition maîtrisée.
Nouveaux comportements et changements de configuration
TypeScript 7 adopte les défauts introduits en 6.0. Plusieurs options changent de valeur par défaut, deux méritent une attention particulière :
rootDirpasse à./par défaut. Les projets oùtsconfig.jsonest en dehors desrcdevront le spécifier explicitement.typespasse à[]par défaut. Les déclarations globales (@types/node, @types/jest, etc.) devront être listées explicitement dans la configuration.
Certaines options deviennent des erreurs bloquantes : target: es5, moduleResolution: node/node10, baseUrl, ou encore module: amd. La migration depuis TypeScript 6.0 est directe. Depuis des versions antérieures, il faudra passer par 6.0 d’abord.
Ce qu’il faut retenir
- TypeScript 7 est une réécriture complète en Go avec des gains de performance réels entre 8x et 12x sur des projets de production mesurés.
- La parallélisation native du parsing, de la vérification de types et de l’émission est le moteur principal de ces gains.
- L’API publique n’est pas encore disponible en 7.0 : un package de compatibilité
@typescript/typescript6permet une cohabitation propre avec les outils qui en dépendent. - Les changements de défauts sur
rootDirettypessont les points de friction les plus courants lors de la migration. - TypeScript 7 est disponible dès maintenant via
npm install -D typescript. Les builds de nuit continueront sous le tagtypescript@next.
Si vous travaillez sur un projet TypeScript conséquent, cette version mérite une évaluation rapide dans un environnement de test. Les retours des équipes Slack, Canva, Figma ou Vanta sont suffisamment cohérents pour que le risque soit limité.
Vous avez déjà testé TypeScript 7 sur votre codebase ? Les questions sur la migration ou la configuration avancée, c’est le genre de sujet dont je parle régulièrement ici. Suivez le blog pour la suite.