Décisions de mise à niveau vers TypeScript 7 : vérificateurs parallèles, mode surveillance et lacunes API

TypeScript 7 représente une version majeure inhabituelle : le langage que vous écrivez reste identique, tandis que l’outil chargé de le vérifier et de le compiler a été remplacé. Pour la plupart des équipes, cette mise à niveau apporte une forte amélioration de la vitesse sans nécessiter de corrections, mais pour celles dont les outils communiquent directement avec le compilateur, cela peut constituer un obstacle. Ce guide explique ce qui diffère réellement entre les versions 6 et 7, comment utiliser les nouveaux contrôles de parallélisme, ainsi que la manière de déterminer si votre projet doit être mis à jour immédiatement ou attendre une nouvelle version.

Le blog a déjà abordé en détail les gains de vitesse liés à la réécriture en Go ainsi que les raisons pour lesquelles ce port a endommagé les outils de vérification et ceux des frameworks ; ici, l’accent est mis sur la décision pratique de mise à niveau.

Même langage, nouveau moteur

Lors de la rédaction de ce texte, TypeScript 7.0 est sorti en version stable (date annoncée : 8 juillet 2026 ; consultez les notes de version pour connaître l’état actuel). Il s’agit d’une réécriture du compilateur, réalisée en Go à partir de TypeScript, projet annoncé par Microsoft en mars 2025 sous le nom de code Corsa. Il ne s’agit pas d’une nouvelle version du langage au sens habituel : il n’y a pas de nouvelle syntaxe, les sémantiques du système de types doivent rester inchangées, et les fichiers .ts existants ne devraient pas présenter de problèmes. Votre code reste identique ; ce qui change, c’est le mécanisme sous-jacent.

Pourquoi le compilateur a dû être réécrit

Jusqu’à TypeScript 6, y compris, le compilateur était écrit en TypeScript et exécuté sur un moteur JavaScript, ce qui signifiait en pratique l’utilisation d’un seul thread pour la vérification des types. Cela posait des problèmes dans les grands monorepos, qui se manifestaient de trois manières courantes :

• Le chargement d’un projet par les éditeurs prenait tant de temps que les développeurs ont appris à attendre.
• Les vérifications de type dans l’environnement CI duraient des minutes à chaque exécution.
• L’utilisation de la mémoire était si élevée que les ordinateurs portables avaient des difficultés notables pour fonctionner.

L’équipe a optimisé l’implémentation en JavaScript pendant des années et a conclu que le goulot d’étranglement résidait dans l’environnement de exécution lui-même et non dans les algorithmes. Ainsi, le vérificateur a été porté sur Go, en conservant délibérément sa structure aussi proche que possible du code existant. Ce choix est important : c’est une portée fidèle et non une refonte qui permet de limiter les écarts de comportement entre 6 et 7.

Quelles sont les différences en pratique

Vérification de type beaucoup plus rapide

Les benchmarks publiés par Microsoft montrent l’ampleur de l’amélioration : la vérification des types dans le codebase de VS Code est passée de 77,8 secondes à 7,5 secondes, soit environ dix fois plus rapide, tandis que Playwright est passé de 11,1 secondes à 1,1 seconde. Deux facteurs contribuent à cela. Le compilateur s’exécute désormais en code machine natif plutôt qu’en JavaScript exécuté par un moteur, et il peut effectuer des vérifications en parallèle à l’aide de goroutines, ce que le vieux design monolithique à un seul thread ne pouvait jamais faire. Vos propres résultats dépendront de la structure de votre projet ; de nombreux petits fichiers indépendants se parallélisent mieux qu’un ensemble énorme de types entremêlés.

Nouveaux contrôles en ligne de commande pour le parallélisme

Votre tsconfig.json ne change pas, car il décrit le langage et le projet, et non la manière dont le compilateur planifie son travail. La configuration ci-dessous est valable pour les deux versions :

// tsconfig.json — nothing changes here, this is the language, not the compiler
{
  "compilerOptions": {
    "strict": true,
    "target": "ES2022"
  }
}

Les nouveaux paramètres se trouvent désormais en ligne de commande. --checkers définit le nombre d’ouvriers de vérification de type qui s’exécutent en parallèle, --builders contrôle le nombre de constructions de références de projet qui se déroulent en même temps, et --singleThreaded désactive complètement le parallélisme :

# But at the CLI level, TypeScript 7 gives you real knobs to turn:
tsc --checkers 4        # number of parallel type-checker workers
tsc --builders 2        # parallel project-reference builds
tsc --singleThreaded    # opt out entirely, useful for reproducible CI logs

Le mode à un seul thread est utile lorsque l’on a besoin de journaux CI déterministes et faciles à lire, ou lorsqu’on cherche à résoudre un problème de mise en ordre suspecté. Sur des machines CI partagées, limiter --checkers au nombre de cœurs disponibles évite de surcharger la machine ; plus d’ouvriers signifie également plus de mémoire utilisée en même temps, il est donc préférable d’évaluer plutôt que de maximiser aveuglément.

Un mode d’observation retravaillé

Dans les grands projets, l’ancien outil de surveillance des fichiers basé sur des requêtes périodiques posait des problèmes récurrents, car tsc --watch mettait du temps à réagir aux modifications. TypeScript 7 transpose l’approche de surveillance des fichiers utilisée par le watcher de Parcel en Go, ce qui permet aux recompilations de commencer immédiatement après avoir enregistré des modifications, sans retard.

Emballage simplifié

Pendant la période de bêta, utiliser le compilateur natif nécessitait l’installation d’un package distinct @typescript/native-preview. Avec la version 7.0, tout est à nouveau regroupé sous le nom de package standard, ce qui rend l’installation identique à celle utilisée auparavant :

npm install -D typescript

Si vous avez testé la version bêta, supprimez ce package supplémentaire ainsi que tous les scripts qui appelaient son exécutable séparé, afin de ne pas avoir à utiliser deux compilateurs en même temps.

Le véritable problème : l’API programmative

C’est cette partie qui détermine de nombreuses mises à niveau. Les outils basés sur l’API du compilateur TypeScript, tels que les plugins language-service, les règles de lint personnalisées et les codemods, ne peuvent pas encore compter sur une API programmative stable pour le compilateur Go 7.0 ; à l’heure de la rédaction, on s’attend à ce qu’elle soit disponible dans une version ultérieure, la 7.1 étant mentionnée comme cible. Si votre pipeline utilise une fonction comme ts.createProgram() pour analyser le programme, vérifiez soigneusement cette approche avant de la passer en production.

Un scénario de migration réaliste

Considérez un monorepo de taille moyenne avec Next.js, contenant environ 40 000 lignes de TypeScript ainsi que plusieurs références à des projets. Une mise à jour vers 7.0 dans un tel environnement peut faire passer le temps de exécution de tsc --noEmit d’environ 52 secondes à environ 6. Une économie de 46 secondes par exécution peut sembler modeste, mais elle s’applique à chaque job CI, à chaque hook pré-commit et à chaque vérification manuelle lors du débogage ; au sein d’une équipe, cela représente des heures supplémentaires chaque semaine.

Pour les projets qui n’utilisent tsc que pour la vérification et la compilation, la migration elle-même est généralement peu significative : il suffit de mettre à jour le paquet, d’exécuter le vérificateur et de s’assurer qu’il passe sans modification du code.

npm install -D typescript@latest
npx tsc --noEmit   # ran clean, zero code changes needed

Un exécution réussie est le résultat attendu, mais pas une garantie. Conservez les résultats de TypeScript 6 à des fins de comparaison et comparez les erreurs signalées lors de la première exécution, car des cas limites sont toujours possibles dans un projet aussi vaste.

Faut-il mettre à jour maintenant ?

• Mettre à jour maintenant si vous utilisez tsc uniquement pour la vérification de types et les compilations. Il s’agit en fait d’une amélioration directement applicable.
• Attendre ou diviser si vous dépendez de l’API programmative du compilateur via des outils personnalisés, des plugins d’éditeur ou des codemods. Patientez jusqu’à l’API stable, ou conservez TypeScript 6 installé pour ces outils tout en utilisant 7 pour les vérifications.
• Y accorder la priorité si vous gérez un très grand monorepo où les minutes passées en CI représentent un coût réel. Les économies de temps peuvent compenser les efforts de migration en quelques jours seulement.

Points clés

• TypeScript 7 modifie le compilateur, pas le langage ; votre tsconfig.json et vos fichiers sources restent inchangés.
• L’amélioration de vitesse provient du code natif ainsi que de la vérification en parallèle, ce dont vous pouvez ajuster les paramètres avec --checkers, --builders et --singleThreaded.

Le principal risque ne réside pas dans votre code, mais dans les outils qui intègrent le compilateur ; faites donc l’inventaire de ceux-ci avant de changer.

Si la vérification lente était votre principale plainte concernant TypeScript, la version 7 y remédie en grande partie ; si vous dépendez des fonctionnalités internes du compilateur, attendez encore une mise à jour.