TypeScript 7.0 est disponible en version stable

Microsoft a annoncé le 8 juillet 2026 la disponibilité de TypeScript 7.0 en version stable. Après la bêta d’avril et la Release Candidate de juin, cette version introduit officiellement le nouveau compilateur natif, porté de TypeScript/JavaScript vers Go.

Microsoft présente cette version comme compatible avec le comportement de TypeScript 6.0, mais avec des temps de compilation et de réponse en éditeur en nette baisse. L’équipe évoque des gains généralement situés entre 8x et 12x sur des builds complets.

Dans les mesures publiées par l’équipe TypeScript, le projet VS Code passe par exemple de 125,7 secondes avec TypeScript 6 à 10,6 secondes avec TypeScript 7. Sentry passe de 139,8 secondes à 15,7 secondes, Playwright de 12,8 secondes à 1,47 seconde et tldraw de 11,2 secondes à 1,46 seconde. La consommation mémoire agrégée baisse aussi dans les exemples fournis, de 6 % à 26 % selon les projets.

La version stable s’installe avec le paquet typescript classique :

npm install -D typescript

Le binaire tsc pointe alors vers TypeScript 7.0 :

npx tsc --version

Le paquet historique de préversion @typescript/native-preview perd donc son rôle central. Microsoft indique que les nightlies doivent bientôt reprendre via le canal habituel :

npm install -D typescript@next

Une compilation plus parallèle

TypeScript 7.0 utilise le multithreading pour plusieurs étapes, dont l’analyse, la vérification de types et l’émission. Trois options permettent d’ajuster ce comportement :

• --checkers, pour configurer le nombre de workers de vérification de types ;
• --builders, pour contrôler le nombre de builders parallèles avec les références de projets ;
• --singleThreaded, pour désactiver la parallélisation, utile en debug ou sur des environnements très contraints.

Microsoft indique que le réglage par défaut utilise 4 checkers. Sur de grosses bases de code, monter à --checkers 8 peut encore améliorer les temps de compilation, mais au prix d’une consommation mémoire plus élevée. Dans un monorepo ou une CI limitée, il faudra donc tester avant de généraliser.

Le mode --watch a également été reconstruit autour d’un watcher inspiré de Parcel, porté en Go. Le but est de limiter le polling coûteux, en particulier sur les projets avec beaucoup de fichiers ou de dépendances dans node_modules.

Une transition à préparer depuis TypeScript 6.0

TypeScript 7.0 reprend les nouveaux comportements de TypeScript 6.0. Un projet propre sous TypeScript 6.0, avec stableTypeOrdering actif et sans option de dépréciation ignorée, devrait produire les mêmes diagnostics avec TypeScript 7.0.

Les points à vérifier restent importants :

• strict passe à true par défaut ;
• module vaut esnext par défaut ;
• noUncheckedSideEffectImports est activé par défaut ;
• rootDir vaut maintenant ./, ce qui peut nécessiter un rootDir: "./src" explicite ;
• types vaut [] par défaut, les déclarations globales doivent donc être listées explicitement si nécessaire ;
• plusieurs options anciennes deviennent des erreurs ou ne sont plus supportées, dont target: es5, downlevelIteration, moduleResolution: node/node10, moduleResolution: classic, baseUrl, certains formats de modules historiques et esModuleInterop: false.

Un autre changement concerne les template literal types : TypeScript 7.0 préserve mieux les points de code Unicode lors de l’inférence. Le comportement devient plus cohérent pour les emojis et caractères hors BMP, mais peut casser des utilitaires de types qui manipulaient volontairement des unités UTF-16.

Attention aux outils qui embarquent TypeScript

La limite principale de TypeScript 7.0 concerne l’API. Microsoft précise que cette version ne fournit pas encore d’API programmatique stable. Une nouvelle API est attendue avec TypeScript 7.1.

En attendant, certains outils qui intègrent directement TypeScript dans leur propre serveur de langage ou compilateur doivent rester prudents. Microsoft cite notamment les workflows autour de Vue, MDX, Astro, Svelte et Angular, qui peuvent encore dépendre de TypeScript 6.0 pour certaines intégrations.

Pour faciliter la cohabitation, Microsoft publie le paquet @typescript/typescript6, avec un exécutable tsc6 et une API TypeScript 6.0 réexportée. Un projet peut donc utiliser TypeScript 7.0 pour tsc, tout en conservant TypeScript 6.0 pour des outils qui importent encore l’API historique.

Exemple d’alias côté package.json :

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

Et dans l’éditeur ?

TypeScript 7.0 repose sur le Language Server Protocol pour son serveur de langage. VS Code dispose d’une extension dédiée à TypeScript 7, tandis que Visual Studio peut activer cette version automatiquement selon le workspace.

Microsoft indique aussi que plusieurs manques de la bêta ont été comblés : semantic highlighting, tri des imports, suppression des imports inutilisés, auto-imports, inlay hints, code lenses, JSX linked editing ou encore tag completions.

Pour les équipes qui travaillent sur de grosses bases TypeScript, l’intérêt principal se situe dans les temps de build, les boucles de feedback en local et la réactivité du serveur de langage. La prudence reste toutefois de mise sur les chaînes d’outils très dépendantes de l’API TypeScript historique.

Si vous avez 5 minutes, j’ai réalisé un mini benchmark sur une codebase de 262k lignes de TypeScript, dans la vidéo ci-dessous :

Sources : Microsoft - TypeScript 7.0 · Microsoft - RC · Microsoft - bêta.