TypeScript 7.0 (Project Corsa) : Guide de migration 2026 — Compilateur Go, builds 10x plus rapides

TypeScript 7.0 — nom de code Project Corsa — représente le changement le plus important dans les 13 ans d'histoire de TypeScript. Le compilateur entier a été réécrit de TypeScript vers le langage Go, offrant une exécution native et un vrai parallélisme en mémoire partagée. Résultat : un vérificateur de types souvent 10 fois plus rapide que TypeScript 6.0, avec 50% moins de mémoire utilisée.

La version bêta est arrivée le 21 avril 2026. La version stable est attendue dans quelques mois. Ce guide vous accompagne étape par étape dans la migration de votre projet.

Prérequis

Avant de commencer, assurez-vous de disposer de :

• Node.js 18 ou supérieur
• Un projet TypeScript existant en version 5.x ou 6.x
• Une bonne connaissance de la configuration tsconfig.json
• npm, pnpm ou yarn installé

Qu'est-ce que le Project Corsa ?

Le compilateur TypeScript actuel est un programme JavaScript monothread tournant sur Node.js. Pour les grandes bases de code, cela crée un plafond dur sur la vitesse de vérification des types — vous êtes limité par le JIT de V8 et la boucle d'événements unique de JavaScript.

Le Project Corsa brise ce plafond de deux manières :

Exécution native : tsgo est un binaire Go compilé. Au lieu de charger un gros bundle JavaScript dans Node.js, le compilateur s'exécute en code machine natif avec un accès direct au CPU.

Parallélisme en mémoire partagée : Le modèle de goroutines de Go permet à plusieurs workers de vérification de types de travailler simultanément sur différentes parties de la base de code, en partageant la mémoire plutôt qu'en sérialisant des messages comme le fait worker_threads de Node.js.

Le portage était méthodique plutôt qu'une réécriture complète — la logique de vérification des types est structurellement identique à l'original. La compatibilité dépasse 98%, avec seulement 74 différences connues par rapport à TS 6.0. Il a déjà été validé sur des bases de code de plusieurs millions de lignes chez Bloomberg, Figma, Google, Notion, Slack et Vercel.

Pourquoi migrer vers TypeScript 7.0 ?

• Vérification des types 10x plus rapide — un check de 60 secondes devient environ 6 secondes
• Vérification parallèle via --checkers N (par défaut : 4 workers)
• Réduction de 50% de la mémoire grâce aux goroutines en mémoire partagée
• Coûts CI réduits — moins de minutes de build par pipeline
• Serveur de langage plus rapide — l'extension VS Code répond nettement plus vite
• Compatibilité 98%+ avec la vérification des types de TS 6.0

Étape 1 : Installer TypeScript 7.0 Bêta

Pendant la période bêta, TypeScript 7.0 est publié sous le package @typescript/native-preview :

npm install -D @typescript/native-preview@beta

Ou avec pnpm :

pnpm add -D @typescript/native-preview@beta

Vérifiez l'installation :

npx tsgo --version
# Version 7.0.0-beta

Le binaire tsgo est un remplacement direct de tsc et accepte les mêmes options.

Étape 2 : Lancer votre premier check tsgo

Lancez une vérification complète des types sans aucun changement de configuration :

npx tsgo --noEmit

Pour un fichier tsconfig spécifique :

npx tsgo -p tsconfig.build.json --noEmit

Comparer les vitesses

Chronométrez les deux compilateurs pour mesurer la différence sur votre projet :

time npx tsc --noEmit
time npx tsgo --noEmit

La plupart des projets Next.js ou Node.js de taille moyenne constatent une accélération de 5 à 10x immédiatement.

Étape 3 : Auditer votre tsconfig.json

TypeScript 7.0 modifie plusieurs valeurs par défaut et supprime des options héritées. Auditez votre configuration :

npx tsgo --noEmit 2>&1 | grep -iE "deprecated|removed|unsupported|no longer"

Valeurs par défaut modifiées

Le changement le plus impactant est types: []. Si votre projet dépendait de l'inclusion automatique de @types/node, vous devez maintenant le déclarer explicitement :

{
  "compilerOptions": {
    "types": ["node", "jest", "react"]
  }
}

Étape 4 : Corriger les changements majeurs

TypeScript 7.0 supprime plusieurs options de configuration héritées. Voici les plus courantes :

Supprimer target: "es5"

Le ciblage ES5 n'est plus pris en charge — TypeScript 7.0 ne contient plus d'émetteur JavaScript pour les anciennes versions. Déléguez la sortie ES5 à votre bundler (Vite, Rolldown ou esbuild) :

// Avant (TS 6.0)
{ "compilerOptions": { "target": "es5" } }
 
// Après (TS 7.0)
{ "compilerOptions": { "target": "es2022" } }

Remplacer baseUrl par paths

baseUrl a été supprimé. Migrez vers paths avec des ancres relatives explicites :

// Avant
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": { "@components/*": ["components/*"] }
  }
}
 
// Après
{
  "compilerOptions": {
    "paths": { "@components/*": ["./src/components/*"] }
  }
}

Mettre à jour moduleResolution

Les stratégies node et node10 sont supprimées. Utilisez bundler pour la plupart des projets modernes :

{
  "compilerOptions": {
    "moduleResolution": "bundler"
  }
}

Supprimer downlevelIteration

Cette option n'est plus valide — supprimez-la entièrement de votre configuration.

Supprimer les formats de modules hérités

module: "amd", module: "umd", module: "system" et module: "none" sont tous supprimés. Migrez vers "esnext" ou "nodenext" :

{
  "compilerOptions": {
    "module": "esnext"
  }
}

Définir rootDir explicitement

TypeScript 7.0 définit rootDir par défaut à "./". Si vos sources sont dans un sous-dossier, spécifiez-le explicitement :

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["./src"]
}

Étape 5 : Activer la vérification parallèle des types

Le plus grand avantage de TypeScript 7.0 est la vérification parallèle. Par défaut, il lance 4 goroutines workers (--checkers 4). Ajustez selon votre machine ou votre environnement CI :

# 8 workers sur une machine CI puissante
npx tsgo --noEmit --checkers 8
 
# Mode monothread pour le débogage
npx tsgo --noEmit --singleThreaded

Pour les monorepos utilisant les références de projets, les builds parallèles utilisent --builders :

npx tsgo --build --builders 4

Ajoutez dans votre pipeline CI :

# .gitlab-ci.yml
typecheck:
  image: node:22
  script:
    - npm ci
    - npx tsgo --noEmit --checkers 4

Ou dans package.json :

{
  "scripts": {
    "typecheck": "tsgo --noEmit",
    "typecheck:ci": "tsgo --noEmit --checkers 8"
  }
}

Étape 6 : Intégration VS Code

Installez l'extension VS Code officielle pour le serveur de langage TypeScript 7.0 :

1. Ouvrez le panneau Extensions (Ctrl+Shift+X)
2. Recherchez "TypeScript Native Preview"
3. Installez et rechargez VS Code

Configurez votre workspace pour utiliser la version installée dans le projet :

// .vscode/settings.json
{
  "typescript.tsdk": "node_modules/@typescript/native-preview/lib",
  "typescript.enablePromptUseWorkspaceTsdk": true
}

Vous remarquerez un IntelliSense nettement plus rapide et une mise en évidence des erreurs quasi instantanée sur les grands fichiers.

Étape 7 : Faire tourner TypeScript 6 et 7 en parallèle

Pendant la migration, installez TypeScript 6.0 à côté de 7.0 pour comparer les résultats :

npm install -D typescript@npm:@typescript/typescript6

Lancez les deux pour vérifier qu'aucune nouvelle erreur n'est introduite :

# Check TS 6
npx tsc --noEmit
 
# Check TS 7
npx tsgo --noEmit

Si TypeScript 7.0 signale de nouvelles erreurs absentes de TS 6.0, ce sont de vraies erreurs de types que les valeurs par défaut plus strictes font remonter. Corrigez-les plutôt que de les supprimer.

Tester votre migration

Après avoir complété toutes les mises à jour de tsconfig, lancez une validation complète :

# Vérification complète des types
npx tsgo --noEmit
 
# Build (si vous utilisez tsc pour l'émission)
npx tsgo -p tsconfig.build.json
 
# Reconstruction forcée des références de projets
npx tsgo --build --force

Benchmarks de performance

Données de performance réelles provenant de bases de code en production :

La mémoire passe généralement de 1,2 GB à moins de 600 MB pour un projet de 1000 fichiers.

Résolution des problèmes courants

"Option 'baseUrl' is no longer supported" — Migrez vers paths avec des chemins relatifs (étape 4).

"Option 'target' value 'es5' is not valid" — Définissez target à "es2022" ou supérieur.

"Option 'types' default changed" — Ajoutez "types": ["node"] (ou vos packages @types) à compilerOptions.

TypeScript 7.0 trouve de nouvelles erreurs — Ce sont de vraies erreurs de types. Les causes les plus fréquentes : strict: true activant strictNullChecks/noImplicitAny, et noUncheckedSideEffectImports: true. Corrigez-les avec des annotations de types appropriées.

VS Code affiche toujours l'ancienne version TypeScript — Appuyez sur Cmd+Shift+P → "TypeScript: Select TypeScript Version" → "Use Workspace Version".

Prochaines étapes

• Suivez la version stable — TypeScript 7.0 stable est attendu dans les deux mois suivant la bêta d'avril 2026. Abonnez-vous au blog TypeScript pour les annonces.
• Associez-le avec Vite 8 et Rolldown — Combinez la vérification native en Go de TypeScript 7.0 avec le bundling natif en Rust de Rolldown pour un pipeline de build entièrement natif.
• Explorez les références de projets — Le flag --builders rend les reconstructions de grands monorepos nettement plus rapides.
• Signalez les cas limites — Soumettez les différences de vérification des types sur le dépôt GitHub TypeScript.

Conclusion

TypeScript 7.0 (Project Corsa) est un changement fondamental, pas une release incrémentale. La réécriture en Go apporte des vitesses d'exécution natives et un vrai parallélisme multithreadé qu'aucun runtime JavaScript ne peut égaler. Pour les équipes de développement qui font tourner TypeScript dans des pipelines CI/CD, l'amélioration de vitesse 10x se traduit directement en boucles de feedback plus courtes et en coûts de calcul cloud réduits.

Le chemin de migration est clair : installez @typescript/native-preview@beta, lancez npx tsgo --noEmit, corrigez la poignée de changements majeurs de configuration, et profitez d'une vérification des types nettement plus rapide. Avec une compatibilité de vérification des types supérieure à 98%, le risque est faible et le bénéfice est substantiel.