TypeScript 7.0 passe au compilateur Go pour une vitesse optimale

Pendant environ quatorze ans, le compilateur TypeScript a pu se compiler lui-même. tsc était un TypeScript qui se compilait en JavaScript et fonctionnait sous Node. À mesure que les répertoires atteignaient des millions de lignes, cette architecture auto-hébergée est devenue un goulot d’étranglement.

TypeScript 7.0 change la langue hôte. Le compilateur et le service linguistique ont été transférés de TypeScript vers Go. Microsoft décrit ce travail comme une portée plutôt qu’une réécriture : la structure de vérification des types reste identique à celle de 6.0, mais l’exécution se fait via du code natif avec un parallélisme basé sur la mémoire partagée. Les comparaisons publiées indiquent souvent une accélération d’environ 10× par rapport à TypeScript 6.0.

Un cas d’usage fréquemment cité illustre concrètement ce changement. La vérification de l’arborescence de VS Code — comprenant environ 1,5 million de lignes de TypeScript — est passée d’environ 77,8 secondes à environ 7,5 secondes.

Si les rapports précédents utilisaient le nom de code Project Corsa (avec l’arbre JavaScript existant surnommé Strada), cette version représente la mise en œuvre concrète de ces efforts.

Pourquoi Go, et pourquoi une portée ?

Les spéculations du public citaient souvent Rust. Go a été choisi car il correspondait à la structure du compilateur existant : des graphes complexes, un système de collecte de déchets et des structures cycliques difficiles à recréer à partir de zéro. Cette correspondance a rendu possible une portée ligne par ligne.

Le cadre de la portée est plus important que le nom du langage. Le maintien de l’architecture a permis de conserver les règles en vigueur. Les projets qui effectuent déjà des vérifications de types sous 6.0 avec stableTypeOrdering activé et sans ignoreDeprecations devraient obtenir les mêmes résultats sous 7.0 — un moteur plus rapide, mais pas un système de types différent.

Les tests de charge en production ont été effectués en premier. Pendant plus d’un an, le port a fonctionné avec des structures complexes dans des outils tels que Bloomberg, Figma, Google, Slack, Notion et Vercel avant d’atteindre cet objectif.

Un véritable parallélisme

Auparavant, un seul thread Node limitait le débit de traitement. Les travailleurs natifs éliminent cette contrainte. La version 7 répartit les tâches de parsing, de vérification et d’émission et ajoute des paramètres :

• --checkers définit le nombre de travailleurs de vérification de type en parallèle
• --builders permet le traitement parallèle des constructions de références de projet et des piles dans les monorepos avec --checkers
• --singleThreaded regroupe tout sur un seul cœur pour des fins de débogage et d’obtention de temps de base

Le travail de parsing/émission par fichier augmente en fonction de la taille et de la modularité du répertoire ; les petites applications à un seul fichier bénéficient moins de cette amélioration.

Le mode d’observation a également été réécrit. La surveillance par sondage consommait beaucoup de ressources CPU avec des arbres node_modules très volumineux ; en intégrant le mécanisme de surveillance de Parcel en Go, on réduit cette consommation et on répond plus rapidement aux modifications.

Changements de configuration qui poseront des problèmes aux équipes

TypeScript 6.0 a servi de pont : de nouvelles valeurs par défaut et des dépréciations apparaissaient sous forme d’avertissements. 7.0 les transforme en erreurs graves. Les équipes qui ont déjà utilisé 6.0 ont déjà accompli la majeure partie du travail. Passer directement de 5.x à 7.0 nécessite un temps de nettoyage du fichier tsconfig.json.

Changements notables des valeurs par défaut :

• strict est activé sauf si modifié
• module est réglé sur esnext, tandis que target sélectionne la dernière version stable d’ECMAScript inférieure à esnext
• noUncheckedSideEffectImports est activé par défaut
• libReplacement est désactivé par défaut

stableTypeOrdering reste activé de force

rootDir commence par ./

types débute comme une liste vide

Les documents indiquent que rootDir et types sont les premiers problèmes auxquels les équipes se heurtent — et ceux pour lesquels les corrections sont les plus simples.

Si tsconfig.json se trouve au-dessus d’un dossier src, définissez explicitement rootDir afin que la structure générée reste familière :

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

Puisque types n’importe plus automatiquement tout ce qui se trouve sous node_modules/@types, listez uniquement ce dont vous avez besoin :

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

Les options qui donnaient auparavant des avertissements échouent désormais de manière fatale (elles cessent de fonctionner utilement) :

• Supprimez target: es5 et downlevelIteration
• Remplacez les valeurs anciennes de moduleResolution (node, node10, classic) par nodenext ou bundler
• Éliminez les modes module tels que amd, umd, systemjs et none au profit de esnext ou preserve
• Supprimez baseUrl et exprimez les paths de manière relative par rapport à la racine du projet
• Évitez de définir esModuleInterop / allowSyntheticDefaultImports sur false
• Tenez alwaysStrict activé de manière permanente

Si moduleResolution reste réglé sur la valeur ancienne node après des années sans révision, ce fichier constitue la liste de contrôle pour la migration.

Unicode dans les types de littéraux de template

Les types de littéraux de template suivent désormais les points de code Unicode plutôt que les unités de code UTF-16 :

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// In 7.0:      ["😀", "abc"]
// Previously:  ["\ud83d", "\ude00abc"]

Les compilateurs anciens pouvaient diviser en deux une paire de substituts d’un emoji. Cela reflétait la logique d’indexation de JavaScript et ne correspondait que rarement à l’intention de l’auteur. Désormais, l’itération suit les points de code, tout comme for...of et [...str]. Les outils qui comptaient délibérément les unités UTF-16 ne fonctionneront plus ; tous les autres obtiendront le comportement attendu.

Analyse plus stricte de JavaScript

La vérification des fichiers .js tolérait auparavant davantage d’idiomes propres à JSDoc et à l’époque de Closure. La version 7 resserre cette approche en s’inspirant des règles de .ts :

• Les endroits nécessitant des types rejettent les valeurs nues — privilégiez typeof someValue
• @enum / @class perdent un traitement spécial ; déclarez une véritable classe ou utilisez @typedef
• Un ? nu n’est pas accepté comme type — privilégiez any

Les assertions se terminant par ! ne sont pas prises en charge — écrivez explicitement T

Les anciennes formes function(string): void sont remplacées par (s: string) => void

L’écart de l’API programmative

Une API programmative stable fait encore défaut dans 7.0. Les bibliothèques qui intègrent le compilateur — l’intégration TypeScript d’ESLint, ts-morph, des transformateurs personnalisés, ainsi que des outils d’édition pour les templates Vue, Svelte, Astro, MDX ou Angular — ne peuvent donc pas encore passer complètement à cette nouvelle approche. Microsoft considère ce manque comme temporaire et prévoit l’achèvement de l’API pour 7.1 et les versions ultérieures.

Pendant ce temps, utilisez la version 7.0 lorsque les plugins language-server ne sont pas nécessaires. Les équipes Angular, par exemple, peuvent exécuter tsc depuis la version 7.0 pour effectuer rapidement des vérifications CLI à l’échelle du projet, tout en conservant la version 6.0 dans l’éditeur. Un package de compatibilité, @typescript/typescript6, fournit un binaire tsc6 et réexporte l’API de la version 6.0, permettant ainsi aux deux versions de coexister :

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0"
  }
}

Faut-il mettre à jour ?

Avec déjà TypeScript 6.0, la migration est mineure mais les avantages sont importants : il suffit de modifier quelques paramètres de tsconfig pour obtenir des tests CI plus rapides ainsi qu’un démarrage de l’éditeur plus rapide. Pour des versions encore plus anciennes, les incompatibilités existent bel et bien, mais presque toutes ont déjà été signalées.

Installez la version candidate aujourd’hui même :

npm install -D typescript@rc

En ce qui concerne les éditeurs, un add-on pour VS Code prend en charge LSP aujourd’hui, et l’intégration native avec VS Code se développe. Visual Studio détecte la version 7.0 dans l’espace de travail ouvert sans nécessiter d’étape d’installation supplémentaire.

Les responsables affirment que les versions fonctionnelles reprendront leur rythme habituel de plusieurs mois, et la version 7.1 devrait combler le manque lié à l’API d’incorporation.

Résultat final : des règles TypeScript familières, exécutées en tant que code natif.