TypeScript 7.0 est sorti

TypeScript 7.0 est sorti le 8 juillet 2026. C’est un portage natif du compilateur et du serveur de langage, écrit en Go, que l’équipe présente comme dix fois plus rapide. Voici ce qu’il faut retenir avant de migrer.

Les nouveautés principales

Des builds 8 à 12 fois plus rapides

Sur les builds complets, l’équipe annonce des gains typiques de 8 à 12 fois, avec des paramètres par défaut :

Projet	TypeScript 6	TypeScript 7	Gain
vscode	125,7 s	10,6 s	11,9×
sentry	139,8 s	15,7 s	8,9×
bluesky	24,3 s	2,8 s	8,7×
playwright	12,8 s	1,47 s	8,7×
tldraw	11,2 s	1,46 s	7,7×

La mémoire consommée baisse aussi, de 6 % (sentry) à 26 % (bluesky). Dans l’éditeur, l’affichage de la première erreur à l’ouverture d’un fichier du dépôt VS Code passe d’environ 17,5 secondes à moins de 1,3 seconde.

L’installation reste classique, et tsc est fourni par le même paquet :

npm install -D typescript
npx tsc

Parallélisation

TypeScript 7.0 parallélise l’analyse, la vérification de types et l’émission. Trois options pilotent ce comportement :

--checkers (expérimental) fixe le nombre de workers de vérification. La valeur par défaut est 4, et 1 rend la vérification mono-thread. Avec --checkers 8, vscode descend à 7,51 s, au prix de plus de mémoire.
--builders (expérimental) règle le nombre de projets référencés construits en parallèle avec --build. Il se multiplie avec --checkers.
--singleThreaded désactive toute parallélisation, utile pour déboguer ou sur une machine limitée.

Le mode --watch repose désormais sur un portage en Go du moniteur de fichiers de Parcel, sans dépendance à une chaîne d’outils C++.

Changements incompatibles

L’obstacle principal pour l’outillage : TypeScript 7.0 ne fournit pas d’API programmatique stable, et les outils qui en dépendent doivent rester sur TypeScript 6.0.

Cohabiter avec TypeScript 6.0 et l’éditeur

TypeScript 7.0 est livré sans API programmatique, une nouvelle API étant attendue avec la 7.1. Pour les outils qui en dépendent, le paquet @typescript/typescript6 fournit un exécutable tsc6 et réexporte l’API 6.0. L’équipe recommande des alias npm :

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Dans VS Code, l’extension TypeScript 7 devient le choix par défaut, et la prise en charge de TypeScript 7 sera intégrée à VS Code lui-même dans les prochaines semaines. Visual Studio l’active automatiquement selon l’espace de travail. Vue, MDX, Astro, Svelte et la vérification des gabarits Angular ne peuvent pas encore s’appuyer sur TypeScript 7, faute d’API stable pour les plugins du service de langage. Vue, MDX, Astro et Svelte doivent rester pour l’instant sur TypeScript 6.0 ; pour Angular, tsc 7 s’utilise en ligne de commande et TypeScript 6.0 reste celui de l’éditeur.

L’équipe prévoit une sortie tous les trois à quatre mois, avec la 7.1 pour suite.

Nouveaux défauts et dépréciations

L’objectif est de rester fidèle à TypeScript 6.0. Un code qui compile sans erreur en 6.0 (avec stableTypeOrdering actif et sans ignoreDeprecations) doit compiler à l’identique. Les défauts changent toutefois :

strict vaut true ;
module vaut esnext, et target vise la dernière version stable d’ECMAScript avant esnext ;
noUncheckedSideEffectImports vaut true, libReplacement vaut false ;
stableTypeOrdering vaut true et ne peut plus être désactivé ;
rootDir vaut ./ et types vaut [].

Pour retrouver l’ancien comportement de types, il faut le demander explicitement :

{
  "compilerOptions": {
    "types": ["*"]
  }
}

Plusieurs options dépréciées en 6.0 deviennent des erreurs : target: es5, downlevelIteration, moduleResolution: node / node10 et classic (préférer nodenext ou bundler), module: amd, umd, systemjs et none, baseUrl, asserts sur les imports (utiliser with), le mot-clé module dans les déclarations d’espaces de noms, /// <reference no-default-lib /> avec skipDefaultLibCheck, ainsi que esModuleInterop, allowSyntheticDefaultImports et alwaysStrict à false. Passer des chemins de fichiers en ligne de commande quand un tsconfig.json existe échoue aussi, sauf avec --ignoreConfig.

L’inférence des types littéraux de gabarit préserve maintenant les points de code Unicode : HeadTail<"😀abc"> donne ["😀", "abc"] au lieu de couper la paire de substitution. Les utilitaires qui modélisaient des unités UTF-16 peuvent donc casser.

Analyse JavaScript alignée sur TypeScript

Le support de JavaScript est retravaillé pour se comporter comme celui des fichiers .ts. Entre autres, on ne peut plus utiliser une valeur comme type (il faut écrire typeof valeur), @enum n’est plus reconnu, le type ? seul n’est plus valide (utiliser any), @class ne transforme plus une fonction en constructeur, le ! postfixé n’est plus pris en charge (écrire T), le nom d’un type s’écrit dans la balise @typedef, plus à côté d’un identifiant, les types de fonction à la Closure ne sont plus pris en charge, et l’aliasing de this comme la réaffectation du prototype d’une fonction ne sont plus traités spécialement. Le détail figure dans le fichier CHANGES.md du dépôt typescript-go.

À retenir

TypeScript 7.0 est le portage natif du compilateur : les builds sont 8 à 12 fois plus rapides, à condition de migrer avec méthode. Vérifiez les nouveaux défauts (strict, module, types), les options dépréciées devenues des erreurs, et gardez TypeScript 6.0 pour les outils qui dépendent de l’API programmatique ou du service de langage.