Si vous avez déjà fixé le petit indicateur de chargement de votre éditeur en attendant qu'une erreur de type s'affiche, ou regardé une CI mouliner de longues minutes sur la seule vérification des types, cette sortie va vous parler. TypeScript 7 s'attaque frontalement à ce point de friction quotidien.
TypeScript 7 est la première version majeure à embarquer un compilateur natif écrit en Go, offrant des gains de vitesse de 8x à 12x sur les compilations complètes. Concrètement, un projet comme VS Code passe de 125 secondes à environ 10 secondes de build, et l'affichage de la première erreur dans l'éditeur chute de 17,5 secondes à moins de 1,3 seconde. Il s'installe simplement via npm install -D typescript.
Dans cet article, nous allons décortiquer ce que change réellement TypeScript 7, comment l'installer, comment gérer la migration depuis les versions précédentes, et surtout quels pièges éviter pour ne pas casser vos projets existants.
Qu'est-ce que TypeScript 7 exactement ?
TypeScript 7 n'est pas une simple évolution incrémentale du langage.
C'est un portage natif complet du compilateur, réécrit du langage TypeScript/JavaScript vers le langage Go.
Annoncé initialement par Microsoft en mars 2025 sous le nom de code Project Corsa (le dépôt public s'appelle typescript-go), cet effort visait un objectif précis : diviser par 10 les temps de compilation et réduire drastiquement la consommation mémoire sur les grandes bases de code.
Anders Hejlsberg, architecte principal de TypeScript chez Microsoft, résumait ainsi la promesse : l'implémentation native améliore considérablement le démarrage de l'éditeur, divise par 10 la plupart des temps de construction et réduit sensiblement l'utilisation de la mémoire.
Le point crucial à comprendre : le portage a été réalisé fidèlement. L'équipe n'a pas réinventé la logique de vérification des types. Elle a réécrit le code en Go tout en conservant exactement la même structure et la même logique que TypeScript 6.0. Résultat : les erreurs, les messages et les emplacements sont identiques entre les deux compilateurs.
TypeScript reste TypeScript. La syntaxe du langage ne change presque pas. Ce qui change radicalement, c'est le moteur qui compile et vérifie votre code.
Pourquoi Go et pas Rust ou C++ ?
Go a été choisi car il offre un excellent compromis entre performance native, simplicité de la syntaxe, ramasse-miettes intégré (la gestion automatique de la mémoire) et surtout un modèle de concurrence robuste (goroutines et channels, les briques légères de Go pour exécuter et coordonner des tâches en parallèle). Ce dernier point est déterminant : il permet à TypeScript 7 d'exploiter le multithreading en mémoire partagée pour paralléliser l'analyse, la vérification des types et la génération de code.
Surtout, la structure du code Go restait proche de celle du compilateur TypeScript existant, ce qui a autorisé un portage quasi ligne à ligne plutôt qu'une réécriture risquée. À l'inverse, le modèle de propriété (ownership) de Rust interdit les structures cycliques sans contournements lourds, or le vérificateur de types en dépend fortement : l'adopter aurait imposé de repenser le cœur du compilateur, un chantier de plusieurs années avec un risque réel de divergence de comportement.
Des performances qui changent le quotidien du développeur
Les chiffres publiés par Microsoft sur des projets open source réels parlent d'eux-mêmes. Voici les temps de compilation comparés entre TypeScript 6 et TypeScript 7 (avec la valeur par défaut de 4 vérificateurs).
| Projet | TypeScript 6 | TypeScript 7 | Gain |
|---|---|---|---|
| vscode | 125,7 s | 10,6 s | 11,9x |
| sentry | 139,8 s | 15,7 s | 8,9x |
| bluesky | 24,3 s | 2,8 s | 8,7x |
| playwright | 12,8 s | 1,47 s | 8,7x |
| tldraw | 11,2 s | 1,46 s | 7,7x |
Mais le vrai enjeu n'est pas seulement le build final. TypeScript intervient partout dans votre journée : autocomplétion, recherche de références, diagnostics en direct, refactoring, mode watch. C'est là que la friction se ressent le plus.
Une réduction spectaculaire de la mémoire
Contrairement à l'idée reçue selon laquelle « plus rapide = plus gourmand », TypeScript 7 consomme moins de mémoire sur l'ensemble d'une compilation. Les baisses mesurées vont de -6 % (sentry) à -26 % (bluesky), avec par exemple VS Code qui passe de 5,2 Go à 4,2 Go (-18 %).
Des retours d'expérience concrets en entreprise
Plusieurs grandes équipes ont testé TypeScript 7 en conditions réelles avant sa sortie :
- Slack a réduit de 40 % le temps d'attente dans sa file de fusion, faisant passer la vérification de types en CI de 7,5 minutes à 1,25 minute.
- Microsoft News Services a économisé 400 heures par mois d'attente sur les builds CI.
- Canva a vu le temps d'affichage de la première erreur dans l'éditeur passer de 58 secondes à 4,8 secondes.
- Vanta a mesuré une accélération jusqu'à 9x sur l'un de ses plus gros projets.
Sur la fiabilité, le nouveau serveur de langage de TypeScript 7 a réduit de plus de 80 % les échecs de commandes et de plus de 60 % les plantages du serveur par rapport à TypeScript 6.
Ce que ça change concrètement pour vous, même en solo
Au-delà des chiffres, le vrai gain est ailleurs : la boucle de feedback.
Quand la vérification des types passe de plusieurs secondes à une fraction de seconde, vous ne changez pas juste une valeur dans un tableau, vous changez votre façon de coder. Vous itérez plus souvent, vous corrigez les erreurs à l'instant où vous les introduisez, et vous restez dans le flux au lieu d'attendre.
Pour un solopreneur ou une petite équipe, c'est directement du temps rendu. Une CI qui passe de 7 minutes à une minute, ce sont des dizaines de déploiements par semaine qui coûtent moins cher et frustrent moins. Moins d'attente, c'est mécaniquement plus de choses expédiées avec les mêmes moyens.
Et TypeScript 7 n'est pas un cas isolé : il rejoint une vague de fond où les outils JavaScript sont réécrits en langages natifs pour la vitesse (esbuild, SWC, Bun, Oxc...). Le message pour votre stack : la lenteur des outils n'est plus une fatalité qu'on subit, c'est devenu un critère de choix. Ça vaut le coup de regarder, brique par brique, ce que vous pourriez remplacer par une alternative native.
Comment installer et utiliser TypeScript 7
L'installation reste identique aux versions précédentes. Vous récupérez le nouvel exécutable tsc natif directement dans votre espace de travail.
npm install -D typescript
npx tsc --versionPour les builds « nightly » (les versions de développement publiées chaque nuit), qui étaient auparavant distribués via le package @typescript/native-preview (plus de 8,5 millions de téléchargements hebdomadaires), la distribution reprend désormais sous le package standard avec la balise next :
npm install -D typescript@next
Support des éditeurs et LSP
TypeScript 7 introduit une prise en charge native du Language Server Protocol (LSP), le protocole standard qui permet à un éditeur de dialoguer avec un moteur d'analyse de code. Concrètement, votre éditeur favori (VS Code, Visual Studio, WebStorm) bénéficie automatiquement des améliorations de vitesse et du multithreading. VS Code propose déjà une extension dédiée, et Visual Studio active TypeScript 7 automatiquement selon votre espace de travail.
Attention : les workflows utilisant Vue, MDX, Astro, Svelte ou la vérification de types spécialisée d'Angular ne peuvent pas encore tirer pleinement parti de TypeScript 7.
La raison : ces outils embarquent le compilateur via son API programmatique, qui n'est pas encore stabilisée. Vérifiez la compatibilité de votre framework.
Le contrôle de la parallélisation : --checkers, --builders et --singleThreaded
C'est l'une des grandes nouveautés techniques.
TypeScript 7 parallélise désormais l'analyse syntaxique, la vérification des types et la génération de code. Certaines étapes se parallélisent facilement (analyse, émission), d'autres non (vérification des types, qui dépend de l'ordre relatif des informations).
Le drapeau --checkers
TypeScript 7 crée un nombre fixe de « workers » de vérification de types, chacun avec sa propre vision du programme. Par défaut, ce nombre est de 4. Vous pouvez l'ajuster :
# Utiliser 8 vérificateurs pour accélérer sur une grosse machine
npx tsc --checkers 8
# Réduire à 1 (monothread) pour économiser la mémoire en CI
npx tsc --checkers 1Augmenter le nombre de checkers accélère les builds sur les machines multicœurs, mais au prix d'une consommation mémoire accrue. Avec --checkers 8, VS Code passe de 10,6 s à 7,51 s (16,7x plus rapide qu'en TypeScript 6).
Le drapeau --builders
Pour les monorepos (un seul dépôt regroupant plusieurs projets) utilisant les références de projet, --builders contrôle le nombre de projets compilés simultanément lors d'un build avec --build :
npx tsc --build --builders 4Attention à l'effet multiplicateur : --checkers 4 --builders 4 autorise jusqu'à 16 vérificateurs simultanés, ce qui peut saturer votre machine.
Le mode --singleThreaded
Pour le débogage, la comparaison de performances ou les environnements aux ressources très limitées, ce drapeau désactive complètement la parallélisation (analyse, vérification et émission sur un seul thread) :
npx tsc --singleThreaded
Un mode --watch entièrement reconstruit
Le mode --watch (qu'on adore tous) a été refondu sur une nouvelle fondation inspirée du file-watcher (le composant qui surveille les fichiers modifiés) du bundler Parcel.
L'équipe a rencontré des difficultés avec la surveillance de fichiers multiplateforme en Go : la bibliothèque standard n'offre pas d'API native, et les solutions par polling (interroger les fichiers en boucle à intervalle régulier) étaient trop coûteuses sur les gros projets avec de nombreuses dépendances dans node_modules.
La solution a consisté à porter le watcher C++ de Parcel vers du Go idiomatique, avec quelques shims en assembleur (de petites couches d'adaptation) pour éviter d'introduire une dépendance à une toolchain C++. Résultat : une surveillance stable, efficace et économe en ressources sur toutes les plateformes.
npx tsc --watch
Migration : les changements de comportement à connaître
TypeScript 7 est compatible avec la vérification de types de TypeScript 6.0.
Concrètement, tout code qui compile proprement en 6.0 devrait compiler à l'identique en 7.0.
Les nouveaux défauts de configuration
| Option | Nouvelle valeur par défaut |
|---|---|
| strict | true |
| module | esnext |
| target | version ECMAScript stable actuelle |
| noUncheckedSideEffectImports | true |
| libReplacement | false |
| stableTypeOrdering | true (non désactivable) |
| rootDir | ./ |
| types | [] (vide) |
Les changements de rootDir et types sont les plus susceptibles de surprendre. Si votre tsconfig.json se trouve en dehors d'un dossier comme src, ajoutez explicitement rootDir :
{
"compilerOptions": {
"rootDir": "./src"
},
"include": ["./src"]
}Pour types, listez explicitement les packages @types dont vous dépendez :
{
"compilerOptions": {
"types": ["node", "jest"]
}
}
Les options désormais interdites (erreurs strictes)
target: es5n'est plus supporté.downlevelIterationn'est plus supporté.moduleResolution: node/node10supprimé (utiliseznodenextoubundler).module: amd, umd, systemjs, nonesupprimés (utilisezesnextoupreserve).baseUrlsupprimé : lespathsdoivent être relatifs à la racine du projet.moduleResolution: classicsupprimé.esModuleInteropetallowSyntheticDefaultImportsne peuvent plus valoirfalse.alwaysStrictest toujourstrue.- Le mot-clé
modulene peut plus être utilisé dans les déclarationsnamespace.
Les projets récents migreront sans difficulté. Les vieux socles Web, eux, devront probablement nettoyer leur tsconfig avant de passer à TypeScript 7. Adoptez d'abord TypeScript 6.0 pour lisser la transition.
Faire cohabiter TypeScript 6 et TypeScript 7
Point important : TypeScript 7.0 ne fournit pas encore d'API programmatique (l'interface qui permet à d'autres outils de piloter le compilateur par code). Celle-ci arrivera avec TypeScript 7.1. En attendant, des outils comme typescript-eslint ont besoin d'un accès programmatique au compilateur.
Microsoft a donc publié un package de compatibilité @typescript/typescript6 qui fournit un exécutable tsc6 et réexporte l'API 6.0.
Pour faire cohabiter les deux versions via des alias npm, modifiez votre package.json :
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}Avec cette configuration, npx tsc utilisera TypeScript 7, tandis que vos outils de linting continueront de s'appuyer sur l'API 6.0.
Une nouveauté de langage : les template literal types et l'Unicode
Au-delà de la performance, TypeScript 7 traite désormais plus naturellement les points de code Unicode lors de l'inférence à partir de template literal types (des types calculés à partir de motifs de chaînes de caractères). Un type comme HeadTail qui découpe une chaîne en tête et queue préserve correctement les caractères Unicode composés de plusieurs unités.
type HeadTail<S> = S extends `${infer Head}${infer Tail}`
? [Head, Tail]
: [S, ""];
Bonnes pratiques pour adopter TypeScript 7
- Migrez d'abord vers TypeScript 6.0 pour absorber les dépréciations progressivement avant le grand saut.
- Nettoyez votre tsconfig : supprimez
baseUrl, mettez à jourmoduleResolutionet déclarez explicitementrootDirettypes. - Ajustez --checkers selon vos environnements : plus élevé en local sur machine puissante, plus bas en CI.
- Fixez un nombre de checkers constant entre environnements pour garantir des résultats reproductibles.
- Testez la compatibilité de vos frameworks (Vue, Svelte, Astro, Angular) avant de basculer en production.
- Utilisez le package de compatibilité si vos outils dépendent encore de l'API compilateur.
Questions fréquentes
TypeScript 7 est-il vraiment 10 fois plus rapide ?
Les gains varient entre 8x et 12x sur les compilations complètes selon les projets et le matériel. Sur des machines à nombreux cœurs avec --checkers 8, certains projets comme VS Code atteignent 16,7x. La performance dépend de la taille du projet, du nombre de cœurs CPU et de la mémoire disponible.
Dois-je réécrire mon code pour passer à TypeScript 7 ?
Non. La syntaxe du langage ne change presque pas et la vérification des types est structurellement identique à TypeScript 6.0. Vous devrez surtout ajuster votre tsconfig.json pour retirer les options dépréciées et déclarer explicitement rootDir et types.
Puis-je utiliser TypeScript 7 avec typescript-eslint ?
Oui, via le package de compatibilité @typescript/typescript6 et des alias npm. TypeScript 7.0 n'ayant pas encore d'API programmatique (prévue pour 7.1), les outils qui en dépendent utilisent l'API 6.0 pendant que tsc tourne en version 7.
TypeScript 7 fonctionne-t-il avec Vue, Svelte ou Angular ?
Pas encore complètement. Les workflows utilisant Vue, MDX, Astro, Svelte ou la vérification de types spécialisée d'Angular ne peuvent pas encore tirer pleinement parti de TypeScript 7. Vérifiez la compatibilité de votre framework avant de migrer.
Pourquoi Microsoft a choisi le langage Go pour réécrire le compilateur ?
Go offre une performance native, un ramasse-miettes, une syntaxe simple et un modèle de concurrence puissant (goroutines) idéal pour le multithreading. Sa structure de code restait suffisamment proche du TypeScript existant pour permettre un portage fidèle plutôt qu'une réécriture complète, garantissant la cohérence des résultats. À l'inverse, le modèle de propriété de Rust, incompatible avec les structures cycliques dont dépend le vérificateur de types, aurait exigé de repenser le compilateur en profondeur.
Où apprendre TypeScript ?
Dans notre formation complète sur TypeScript bien entendu !