TypeScript 7.0 est la version la plus importante de l'histoire de ce langage — non pas pour une nouvelle syntaxe, mais pour ce qui se passe sous le capot. Le compilateur entier a été réécrit en Go, et le résultat est des builds jusqu'à 10x plus rapides, une vérification de types qui se termine en une fraction du temps, et une consommation mémoire réduite de près de 3x.
Si vous travaillez sur une base de code TypeScript de taille significative, cette mise à jour va transformer votre pipeline CI — et la réactivité de votre éditeur.
Qu'est-ce que le Projet Corsa ?
Project Corsa est le nom de code interne de Microsoft pour le portage natif en Go du compilateur TypeScript. L'objectif n'était pas d'introduire de nouvelles fonctionnalités linguistiques, mais de briser le plafond de performance fondamental imposé par l'exécution du compilateur en tant que processus Node.js.
Le tsc basé sur JavaScript était conçu pour la justesse et la portabilité, mais il se heurtait à des murs infranchissables : une boucle d'événements mono-thread, des pauses de ramasse-miettes V8, et des limites mémoire rendant les grands monorepos douloureux. Une base de code d'un million de lignes compilant en 89 secondes était acceptable en 2018 ; en 2026, les développeurs attendent un retour quasi-instantané.
Microsoft a évalué Rust, C# et Go avant de choisir Go. Les raisons étaient pratiques :
- L'architecture fonctionnelle et récursive du compilateur TypeScript s'adapte naturellement aux idiomes Go
- Le ramasse-miettes de Go gère la charge de travail sans gestion manuelle de la mémoire
- esbuild avait déjà prouvé que les outils JavaScript basés sur Go pouvaient atteindre des accélérations spectaculaires
- Porter méthodiquement la base de code (plutôt que de réécrire de zéro) préserve la justesse
La logique de vérification de types dans TypeScript 7 est structurellement identique à TypeScript 6 — seul l'environnement d'exécution a changé.
Benchmarks : Les chiffres sont réels
Microsoft a testé le nouveau compilateur sur les principales bases de code open source :
| Projet | tsc (TS 6) | tsgo (TS 7) | Accélération |
|---|---|---|---|
| VS Code (1,5 M lignes) | 89,1 s | 8,74 s | 10,2x |
| Sentry | 133,1 s | 16,3 s | 8,2x |
| TypeORM | 15,8 s | 1,06 s | 9,9x |
| Playwright | 9,3 s | 1,24 s | 7,5x |
Au-delà du temps de compilation :
- Vérification de types : jusqu'à 30x plus rapide sur les projets de taille moyenne et supérieure
- Utilisation mémoire : 2,9x plus efficace (68 Mo → 24 Mo sur les projets testés)
- Démarrage de l'éditeur : le service de langage VS Code passe de 9,6 s à 1,2 s
Les petites bases de code (moins de 50 000 lignes) voient des gains plus modestes de 2 à 5x — le parallélisme de Go porte ses fruits à grande échelle. Mais même sur un projet de 10 000 lignes, le temps de démarrage à froid diminue sensiblement.
Les changements architecturaux sous le capot
Le nouveau compilateur (tsgo) se compile en un binaire natif pour chaque plateforme — Windows, macOS, Linux et ARM — ce qui signifie qu'il n'y a pas de démarrage Node.js, pas de coût de compilation JIT V8, et pas de pression sur le tas JavaScript.
Les goroutines de Go remplacent la boucle d'événements mono-thread de JavaScript. TypeScript 7 utilise le parallélisme à mémoire partagée pour vérifier les types de plusieurs fichiers simultanément. La valeur par défaut est 4 workers de vérification, configurable via --checkers={count} pour les machines avec plus de cœurs.
Pour les configurations monorepo — Yarn Workspaces, Lerna, Nx — c'est une transformation majeure. Les projets qui devaient attendre des builds de références de projets en série peuvent maintenant exécuter plusieurs packages en parallèle sans outillage d'orchestration supplémentaire.
Ce qui change dans votre code
TypeScript 7 adopte tous les changements non rétrocompatibles de TypeScript 6 comme des erreurs strictes. Si vous migrez depuis TypeScript 5 ou antérieur, le saut est significatif :
Le mode strict est désormais activé par défaut. Auparavant, vous deviez l'activer explicitement ; avec TS7, le mode strict est activé sauf désactivation explicite.
La cible ES5 est supprimée. La cible de sortie minimale est ES2021. Si votre projet cible les navigateurs anciens et s'appuyait sur "target": "es5", vous aurez besoin d'une étape de transpilation séparée (esbuild ou Babel en aval).
Les formats de modules AMD et UMD sont supprimés. Dépréciés depuis des années, TypeScript 7 les supprime entièrement.
La résolution de module ES2015 reste prise en charge, mais node10 (l'ancienne résolution de module Node) est dépréciée en faveur de node16 ou bundler.
Tester tsgo aujourd'hui
TypeScript 7 est en bêta depuis avril 2026, avec une sortie GA prévue au T2 2026. Vous pouvez installer le compilateur en préversion dès aujourd'hui :
npm install -D @typescript/native-previewExécutez-le en parallèle avec votre tsconfig.json existant :
npx tsgo -p . --extendedDiagnosticsNote : tsgo ne supporte pas encore --init. Utilisez tsc --init pour générer votre tsconfig, puis passez à tsgo pour la compilation et la vérification de types.
# Vérification rapide de la version
npx tsgo -v
# Vérification de types uniquement (sans émission) — utile pour la CI
npx tsgo -p . --noEmitPour les builds de production, continuez à utiliser TypeScript 6 jusqu'à la sortie stable GA. Le flux de travail recommandé :
- Exécutez
tsgo --noEmiten CI pour valider les types avec une vitesse 10x - Gardez
tsc(TS6) pour l'étape d'émission jusqu'au GA de TS7
Ce qui n'est pas encore prêt
Soyez conscient de ces limitations actuelles avant de basculer entièrement :
- Le pipeline d'émission JavaScript est incomplet. Le compilateur Go gère bien la vérification de types, mais le pipeline de génération de code est encore en cours de finalisation.
- Les décorateurs ne sont pas encore supportés. Les projets utilisant
@Injectable,@Componentou des patterns similaires (NestJS, Angular) ne peuvent pas encore migrer complètement. - Migration TSServer vers LSP. TypeScript 7 passe du protocole TSServer personnalisé au Language Server Protocol (LSP). La plupart des éditeurs géreront cela de manière transparente, mais les intégrations IDE personnalisées peuvent nécessiter des mises à jour.
Le chemin de migration
Le chemin de mise à niveau le plus propre est progressif :
Étape 1 — Mettre à niveau vers TypeScript 6 en premier. TypeScript 6 (publié le 23 mars 2026) est une version pont. Il active les avertissements du mode strict, signale l'utilisation de la cible ES5, et avertit sur AMD/UMD. Utilisez-le pour identifier et corriger tous les changements non rétrocompatibles avant TS7.
Étape 2 — Installer la préversion native. Ajoutez @typescript/native-preview comme dépendance de développement et exécutez tsgo --noEmit sur votre base de code pour vérifier s'il y a des incompatibilités restantes.
Étape 3 — Migrer la CI vers tsgo pour la vérification de types. Remplacez votre étape CI tsc --noEmit par tsgo --noEmit. Les temps de build diminuent immédiatement ; l'émission de production utilise toujours TS6.
Étape 4 — Attendre le GA pour la migration complète. Une fois que TypeScript 7.0 stable est publié (prévu T2 2026), mettez à jour l'ensemble de votre chaîne d'outils.
Pour les grandes bases de code d'entreprise, prévoyez 1 à 2 sprints pour le chemin TypeScript 5 → 6 → 7. La majeure partie du travail se situe dans l'étape TS5 → TS6 (correction du mode strict et des changements de résolution de modules).
Est-il temps de basculer ?
Pour la validation de la vérification de types aujourd'hui, oui — installez la préversion et mettez tsgo --noEmit dans votre CI. Le gain de vitesse est réel et immédiat, sans changements de code requis pour la plupart des projets.
Pour un usage de production complet, attendez la sortie GA. Le pipeline d'émission JS et le support des décorateurs sont les obstacles restants pour la plupart des applications.
TypeScript 7.0 n'ajoute pas de nouvelle syntaxe ni de nouvelles fonctionnalités au système de types — il accélère toute l'expérience développeur. Une CI plus rapide signifie une itération plus rapide. Une vérification de types plus rapide dans l'éditeur signifie moins de changements de contexte. Pour les équipes travaillant sur de grandes bases de code TypeScript, la mise à niveau n'est pas optionnelle ; elle est attendue.
La réécriture en Go nous rappelle que la meilleure décision d'ingénierie n'est parfois pas une nouvelle fonctionnalité — c'est reconstruire les fondations à un ordre de magnitude différent.