TypeScript 7 : le compilateur natif 10x plus rapide

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.

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).

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 --version

Pour 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.

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 1

Augmenter 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 4

Attention à 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

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: es5 n'est plus supporté.
• downlevelIteration n'est plus supporté.
• moduleResolution: node/node10 supprimé (utilisez nodenext ou bundler).
• module: amd, umd, systemjs, none supprimés (utilisez esnext ou preserve).
• baseUrl supprimé : les paths doivent être relatifs à la racine du projet.
• moduleResolution: classic supprimé.
• esModuleInterop et allowSyntheticDefaultImports ne peuvent plus valoir false.
• alwaysStrict est toujours true.
• Le mot-clé module ne peut plus être utilisé dans les déclarations namespace.

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 à jour moduleResolution et déclarez explicitement rootDir et types.
• 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

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.

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.

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.

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.

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.

Dans notre formation complète sur TypeScript bien entendu !