Faut-il déjà passer à TypeScript 7 ?

Passez à TypeScript 7 dès maintenant si votre projet est en TypeScript pur et compile déjà sans erreur sous 6.0. Si vous dépendez de typescript-eslint, Vue, Svelte, Astro, MDX ou de la vérification des templates Angular, exécutez le tsc de 7.0 en parallèle de 6.0 et attendez la version 7.1 avant de basculer complètement.

Les chiffres de performance sont alléchants. Puis vous vous rappelez que votre pipeline de lint, vos fichiers .vue et un script de génération de code maison importent tous typescript, et une montée de version majeure commence à paraître risquée.

TypeScript 7.0 est sorti le 8 juillet 2026. Cet article détaille l’ampleur réelle du gain de vitesse, les changements de configuration qui casseront votre build, les outils qui ne peuvent pas encore utiliser 7.0 et la manière de faire cohabiter les deux compilateurs dans un même dépôt. Il se termine par une recommandation pour chaque type de projet.

TypeScript 7 est-il vraiment plus rapide ?

TypeScript 7.0 est un portage du compilateur TypeScript en Go, et selon Microsoft, il rend généralement les builds complets 8 à 12 fois plus rapides qu’avec TypeScript 6.0. L’équipe n’a pas repensé le compilateur. La version Go reproduit l’organisation et le fonctionnement du code d’origine, si bien que les deux compilateurs produisent les mêmes résultats. Le gain provient de l’exécution en code natif et d’une vérification de types répartie sur plusieurs threads partageant la mémoire.

Voici les chiffres de builds complets issus de l’annonce de TypeScript 7.0 par Microsoft :

Microsoft a exécuté ces builds avec la valeur par défaut de quatre workers de vérification de types (--checkers 4) sur de grandes bases de code open source. L’annonce ne précise pas le matériel utilisé. Le résultat le plus faible, tldraw à x7,7, se situe juste en dessous de la fourchette « 8 à 12 fois » avancée par Microsoft.

Le temps réellement gagné avec TypeScript 7 dépend de la taille de votre base de code. D’après les chiffres de Microsoft, vscode gagne environ 115 secondes par build complet, tldraw moins de 10. Une petite application dont la vérification de types prend déjà deux secondes bénéficiera d’un ratio d’accélération similaire, mais gagnera très peu de temps.

Trois changements plus mineurs, en une ligne chacun :

• --checkers et --builders contrôlent la vérification de types en parallèle et les builds de références de projet. Les notes de version de 7.0 qualifient ces deux options d’expérimentales.
• --watch repose désormais sur un portage en Go du file watcher de Parcel.
• La vérification JS et JSDoc a été retravaillée pour se comporter davantage comme l’analyse des fichiers .ts. Les détails figurent dans le CHANGES.md de typescript-go.

Ce qui casse lors d’une migration depuis TypeScript 5.x ou 6.0

Un code qui ne présente aucune erreur sous TypeScript 6.0, avec stableTypeOrdering activé et ignoreDeprecations supprimé, devrait produire le même résultat sous TypeScript 7.0. Tout ce qui casse trouve son origine dans 6.0 : 7.0 hérite des nouvelles valeurs par défaut de 6.0, et tout ce que 6.0 a marqué comme déprécié bloque désormais le build. Les équipes qui migrent directement depuis 5.x subissent les deux vagues de changements en même temps.

Nouvelles valeurs par défaut

Quatre valeurs par défaut de TypeScript 7.0, héritées de 6.0, sont à l’origine de la plupart des ruptures :

• strict vaut true. Attendez-vous à de nouvelles erreurs dans le code faiblement typé. Des helpers bien typés construits à partir des utility types de TypeScript facilitent la transition.
• module vaut esnext par défaut.
• rootDir vaut ./ par défaut. Si votre tsconfig.json se trouve au-dessus de src, définissez rootDir explicitement.
• types vaut [] par défaut. Listez nommément les paquets de types globaux comme node ou jest, ou définissez ["*"] pour retrouver l’ancien comportement.

Quatre autres valeurs par défaut ont changé : target suit désormais la plus récente édition ECMAScript finalisée (une étape derrière esnext), noUncheckedSideEffectImports vaut true, libReplacement vaut false, et stableTypeOrdering vaut true sans possibilité de le désactiver.

Dépréciations devenues des erreurs bloquantes

Les notes de version de TypeScript 7.0 recensent douze options et comportements dépréciés qui provoquent désormais une erreur bloquante :

• target: es5
• downlevelIteration
• moduleResolution: node / node10 (utilisez nodenext ou bundler)
• moduleResolution: classic (utilisez bundler ou nodenext)
• module: amd, umd, systemjs, none (utilisez esnext ou preserve)
• baseUrl (écrivez les paths relativement à la racine du projet)
• esModuleInterop ou allowSyntheticDefaultImports définis à false
• alwaysStrict défini à false
• Le mot-clé module dans les déclarations de namespace
• asserts sur les imports (utilisez with)
• /// <reference no-default-lib /> avec skipDefaultLibCheck
• Les chemins de fichiers passés en ligne de commande lorsque le répertoire contient un tsconfig.json, sauf si vous ajoutez --ignoreConfig

outFile ne figure pas dans cette liste, mais il a lui aussi disparu. Les notes de version de 6.0 indiquent que 6.0 l’avait déjà supprimé, et que toutes les options dépréciées par 6.0 sont entièrement supprimées dans 7.0. Si vous utilisez encore outFile, confiez cette tâche à un bundler.

Il existe aussi un changement au niveau des types : l’inférence à partir des template literal types ne scinde plus en deux moitiés un caractère tel qu’un emoji. Vous ne le remarquerez que si vous avez écrit des helpers de chaînes au niveau des types qui s’appuyaient sur l’ancien découpage UTF-16.

Voici une configuration héritée typique et sa version compatible avec 7.0 :

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

La nouvelle version supprime target pour que la valeur par défaut s’applique, fait pointer paths vers la racine du projet, et définit explicitement rootDir et types.

Microsoft recommande de passer d’abord par 6.0. Migrez vers 6.0, corrigez chaque avertissement de dépréciation (l’annonce de TypeScript 6.0 les explique un par un), supprimez ignoreDeprecations, et seulement ensuite installez 7.0.

Quels outils ne fonctionnent pas encore avec TypeScript 7 ?

Les outils qui importent le compilateur TypeScript comme bibliothèque, ainsi que ceux qui assurent la vérification des templates Vue, MDX, Astro, Svelte et Angular, ne fonctionnent pas encore avec TypeScript 7.0, car TypeScript 7.0 ne fournit pas d’API programmatique. Selon l’annonce de 7.0 par Microsoft, les outils qui importent le compilateur comme bibliothèque, comme typescript-eslint, doivent continuer à tourner sur TypeScript 6.0 via le paquet de compatibilité @typescript/typescript6. Si votre configuration de lint avec typage via typescript-eslint repose sur une peer dependency envers typescript, elle nécessite la configuration d’alias décrite dans la section suivante.

Les langages embarqués sont également concernés. L’annonce de 7.0 indique que les projets Vue, MDX, Astro et Svelte doivent rester sur TypeScript 6.0 pour le moment. Volar et les outils similaires intègrent la prise en charge de TypeScript dans ces formats de fichiers en appelant directement le compilateur, et 7.0 n’expose aucune API à appeler. La vérification de types des templates Angular souffre de la même limitation. Pour Angular, l’annonce suggère une approche mixte : utiliser le tsc de 7.0 en ligne de commande et en CI pour détecter rapidement les erreurs sur l’ensemble du projet, et laisser 6.0 piloter l’éditeur afin que la vérification des templates continue de fonctionner.

Dans VS Code, l’extension TypeScript 7 dédiée de Microsoft propose deux commandes dans la palette de commandes, « Disable TypeScript 7 Language Server » et « Enable TypeScript 7 Language Server », pour basculer l’éditeur entre 6.0 et 7.0 à tout moment. Si l’éditeur se comporte de façon anormale après le changement, la méthode habituelle de débogage TypeScript dans VS Code reste valable.

Microsoft prévoit de réintroduire une API dans TypeScript 7.1, sans qu’elle soit identique à l’ancienne. C’est cette version qui marquera, de façon réaliste, le moment où ces intégrations pourront migrer.

Faire cohabiter TypeScript 7 et 6.0

Pour exécuter les deux versions dans un même dépôt, utilisez les alias npm. Faites pointer le nom de paquet typescript vers le paquet de compatibilité 6.0, et installez 7.0 sous un autre nom. Les outils qui importent typescript chargent alors 6.0. Le paquet de compatibilité fournit l’API de 6.0 ainsi qu’une commande 6.0 nommée tsc6.

Dans un projet npm classique, npx tsc exécute alors 7.0. Il y a toutefois un piège. Le paquet de compatibilité dépend d’une copie complète de TypeScript 6.0 qui déclare son propre tsc : deux paquets se disputent donc ce nom de commande. Des utilisateurs ont signalé que Yarn et Bun peuvent lier tsc à 6.0 à la place. Le script typecheck ci-dessous appelle directement le fichier de 7.0, il ne dépend donc pas du paquet qui remporte le nom tsc. Voici la configuration décrite par Microsoft, complétée par des scripts :

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

typecheck exécute 7.0. typecheck:6 exécute 6.0, ce qui permet de vérifier que les deux compilateurs sont d’accord pendant la migration. lint résout typescript vers 6.0 grâce à l’alias. Pour configurer l’alias 6.0 depuis le terminal, lancez npm install -D typescript@npm:@typescript/typescript6. Si vous vous arrêtez là, vous n’obtenez que tsc6 ; ajoutez donc aussi l’alias 7.0.

Lancez npx tsc --version pour savoir quel compilateur un simple tsc appelle. Microsoft ne documente cette configuration que pour npm : vérifiez donc le résultat vous-même si vous utilisez pnpm, Yarn ou Bun.

Faut-il migrer ? Recommandations selon votre situation

L’opportunité de passer à TypeScript 7 dépend de deux critères : la propreté de votre build sous 6.0, et la présence ou non, dans votre chaîne d’outils, d’éléments qui importent le compilateur.

Nouveau projet : démarrez sur 7.0. Si vous migrez de Flow vers TypeScript, visez d’emblée les valeurs par défaut de 7.0 pour éviter une seconde migration.

Petite base de code en TS pur : passez à 6.0, corrigez toutes les dépréciations, puis basculez. Le gain de temps sera modeste, mais vous serez sur la branche maintenue.

Grand monorepo : mettez en place l’alias, faites passer dès maintenant la vérification de types en CI sur le tsc de 7.0, et conservez le lint, la génération de code et l’éditeur sur 6.0 jusqu’à ce que 7.1 publie son API.

Conclusion

TypeScript 7.0 vérifie les types de votre code presque exactement comme 6.0, mais plus rapidement. La quasi-totalité de ce qui casse provient des dépréciations de 6.0 ou des outils qui nécessitent une API du compilateur. Commencez par obtenir un build propre sous 6.0 sans ignoreDeprecations. Ensuite, soit vous basculez complètement, soit vous ajoutez l’alias npm et laissez la CI exécuter le tsc de 7.0 tandis que votre outillage reste sur 6.0 jusqu’à la sortie de 7.1.

FAQ

tsgo ou @typescript/native-preview, est-ce la même chose que TypeScript 7 ?

Plus maintenant. Avant la sortie de 7.0, le compilateur Go était proposé en préversion dans le paquet @typescript/native-preview, avec la commande tsgo. La dernière version de ce paquet est la 7.0.0-dev.20260707.2, publiée la veille de la version stable. Dans TypeScript 7.0, le compilateur natif fait partie du paquet typescript standard et s'exécute via tsc. Les nightly builds proviennent désormais de typescript@next : remplacez donc tsgo par tsc dans vos scripts de CI.

TypeScript 7 accélère-t-il les builds Vite, esbuild ou SWC ?

Non. Vite, esbuild et SWC transforment TypeScript en JavaScript en supprimant les types sans les vérifier : ils n'appellent jamais tsc et leurs temps de transpilation restent inchangés. TypeScript 7 accélère l'étape distincte de vérification de types, généralement tsc --noEmit en CI ou dans un hook pre-commit, ainsi que le language server de l'éditeur. Si la vérification de types n'est pas l'étape la plus lente de votre pipeline, la migration ne raccourcira pas sensiblement vos builds.

ts-node fonctionne-t-il avec TypeScript 7 ?

Pas directement. ts-node compile les fichiers via l'API du compilateur TypeScript, que 7.0 ne fournit pas. Avec la configuration d'alias npm, l'import de typescript par ts-node est résolu vers le paquet de compatibilité 6.0 : ts-node continue donc de tourner sur 6.0 tandis que tsc exécute 7.0. Pour du code n'utilisant que de la syntaxe effaçable, le type stripping des versions récentes de Node.js permet d'exécuter des fichiers .ts sans aucun compilateur, mais sans aucune vérification de types.

TypeScript 7 peut-il encore compiler en ES5 pour les anciens navigateurs ?

Non. TypeScript 6.0 a relevé la cible minimale prise en charge à ES2015 et déprécié target es5. Dans 7.0, target es5 provoque une erreur bloquante. Si vous avez toujours besoin d'une sortie ES5, faites émettre à tsc du ES2015 ou plus récent, puis post-traitez le résultat avec Babel ou un autre compilateur. Vous pouvez aussi compiler directement le code source TypeScript avec cet outil externe.