TypeScript 7.0 : le compilateur natif change la donne, faut-il migrer ?

Un fil du subreddit r/webdev a fait le tour des commentaires cette semaine en relayant l'arrivée de TypeScript 7.0, la version qui généralise le compilateur natif du langage, réécrit en Go. Le chantier n'est pas nouveau : l'équipe TypeScript, menée par Anders Hejlsberg, en avait posé les bases dès mars 2025 sur le blog officiel de Microsoft. Ce qui change avec cette 7.0, c'est le passage du statut de préversion expérimentale à celui d'option pleinement recommandée.

Précision utile avant d'aller plus loin : le fil Reddit d'origine ne détaillait pas de chiffres techniques vérifiables sur cette version précise. Pour rester rigoureux, cet article s'appuie sur la documentation officielle du projet TypeScript et sur son dépôt GitHub pour tous les faits cités. Si vous préparez une migration, vérifiez toujours l'état exact de la compatibilité sur le dépôt officiel avant de basculer un projet en production.

Le compilateur natif, un rappel en trois phrases

Depuis sa création, TypeScript compile et vérifie les types via un compilateur écrit en TypeScript, exécuté sur Node.js. Sur de gros codebases, cette architecture atteint ses limites : le « type checking » complet et le chargement de projet dans l'éditeur deviennent lents à mesure que le code grossit. En mars 2025, l'équipe a annoncé une réécriture du compilateur et du service de langage en Go, avec un objectif affiché : rendre TypeScript jusqu'à dix fois plus rapide sur les tâches de compilation.

Ce qui change concrètement avec la 7.0

La nouveauté de cette version, telle que documentée par le projet, tient en un mot : la généralisation. Le compilateur natif, distribué sous le nom de code tsgo, via le paquet @typescript/native-preview, sort de son statut expérimental pour devenir l'option mise en avant dans le cycle de vie du projet. Concrètement :

• Même langage, autre moteur. La syntaxe TypeScript, le système de types et vos fichiers .ts ne changent pas. Ce qui change, c'est le programme qui les lit et les vérifie.
• Un objectif de performance assumé. Dès l'annonce du projet, l'équipe TypeScript avançait un gain pouvant atteindre dix fois la vitesse du compilateur historique sur les scénarios de compilation complète, un chiffre repris dans la présentation officielle du chantier.
• Une coexistence organisée. Le compilateur historique tsc, écrit en TypeScript, reste disponible et continue de recevoir des correctifs pendant la période de transition. Rien n'oblige à migrer du jour au lendemain.

Comment tester la migration sans tout casser

La bonne pratique consiste à tester le compilateur natif en parallèle de votre chaîne existante, sans remplacer tsc immédiatement. Sur un projet Node ou dans un monorepo :

npm install -D @typescript/native-preview

npx tsgo --project tsconfig.json

Si votre pipeline de CI passe et que les erreurs de typage remontées sont identiques à celles de tsc, vous pouvez ajouter tsgo comme étape de vérification rapide avant vos tests, en gardant l'outil historique pour la génération finale des fichiers .d.ts tant que la parité de fonctionnalités n'est pas totale.

Le point de vigilance concerne l'écosystème autour du compilateur : ESLint et son plugin typescript-eslint, les extensions d'éditeur, les intégrations dans les bundlers comme Vite ou Webpack s'appuient historiquement sur le service de langage écrit en TypeScript. Leur portage vers le moteur natif suit son propre calendrier, distinct de celui du compilateur seul. Avant de retirer tsc de votre pipeline, vérifiez que tous vos outils tiers supportent bien le nouveau moteur.

Qui doit migrer, et quand

Pour une PME ou une agence française avec un ou deux projets front-end de taille moyenne, l'urgence est faible. Le gain de vitesse se fait surtout sentir sur les gros monorepos, où le « type checking » complet peut représenter une part significative du temps de CI à chaque exécution. Sur un petit projet, le temps de compilation actuel est déjà négligeable : migrer n'apportera pas de bénéfice perceptible dans l'immédiat.

En revanche, si vous gérez un monorepo avec plusieurs applications et packages partagés, ou une CI où le typage TypeScript figure parmi les postes de temps les plus longs, tester tsgo dès maintenant sur une branche non critique a du sens. Le retour d'expérience vous prépare pour le jour où le compilateur natif deviendra la valeur par défaut du projet, ce que l'équipe TypeScript présente comme l'objectif à terme de ce chantier.

Notre lecture chez CZSyn

Ce type de bascule technique, un langage qui réécrit son propre outillage dans un autre langage pour gagner en performance, n'est pas isolé. Le message reste le même à chaque fois : la vitesse de compilation et le temps de retour dans l'éditeur sont devenus des critères de productivité aussi importants que les fonctionnalités du langage lui-même, surtout sur des bases de code qui grossissent vite.

Notre recommandation pour les équipes que nous accompagnons : ne migrez pas un projet en production simplement parce qu'une version majeure sort. Testez tsgo sur une branche, mesurez le gain réel sur votre propre CI, et vérifiez la compatibilité de votre chaîne d'outils avant d'y toucher. Sur un projet critique, le compilateur historique reste un choix parfaitement raisonnable tant que l'écosystème (linters, plugins d'éditeur, générateurs de types) n'a pas rattrapé son retard. La bonne nouvelle, c'est que la transition est pensée pour être progressive, pas pour vous forcer la main.

Sources primaires

• Discussion communautaire, « Announcing TypeScript 7.0 » sur r/webdev.
• Microsoft DevBlogs, annonce officielle du portage natif du compilateur TypeScript, « A 10x Faster TypeScript ».
• Dépôt officiel du compilateur natif, github.com/microsoft/typescript-go.
• Documentation officielle, typescriptlang.org.