Microsoft annonce la version bêta de TypeScript 7.0, basée sur le langage Go, avec des performances « 10 fois plus rapides » que la version 6.0, des capacités de traitement parallèle et bien plus encore
Microsoft a annoncé la sortie de TypeScript 7.0 Beta, marquant ainsi le lancement de la version bêta publique de la refonte, basée sur Go, du compilateur et de la suite d'outils du langage. Cette version est présentée comme un changement architectural majeur pour le langage, Microsoft affirmant que la nouvelle implémentation est « environ dix fois plus rapide que TypeScript 6.0 ». Bien qu'il s'agisse d'une version bêta, l'entreprise affirme que le compilateur est prêt pour la production. TypeScript 7.0 Beta est entièrement compatible avec TypeScript 6.0 et apporte plusieurs nouveautés visant à améliorer ses performances, sa stabilité et sa compatibilité.
TypeScript (TS) est un langage de programmation de haut niveau qui ajoute à JavaScript un typage statique avec des annotations de type facultatives. Il est conçu pour le développement d'applications volumineuses et est compilé en JavaScript. TypeScript est développé par Microsoft en tant que logiciel libre et open source, distribué sous licence Apache 2.0. En mars 2025, Microsoft a annoncé que son équipe travaillait sur une version du compilateur TypeScript portée sur Go, qui devrait être publiée sous le nom de TypeScript 7.0. En décembre de la même année, il a été annoncé sur le blog de l'entreprise que TypeScript 6.0 serait la dernière version écrite en TypeScript lui-même, et que TypeScript 7.0 serait la première version basée sur Go.
L'annonce de TypeScript 7.0 Beta est importante non seulement parce qu'elle fait avancer le calendrier de publication de TypeScript 7, mais aussi parce qu'elle officialise l'abandon de l'implémentation de longue date basée sur JavaScript. Dans le billet officiel publié le 21 avril, Microsoft a indiqué que cette version bêta reposait sur « une base entièrement nouvelle », créée en portant le code source existant de TypeScript vers Go, tout en conservant le même comportement de vérification des types et la même sémantique auxquels les développeurs sont déjà habitués.
« Nous sommes ravis d’annoncer la sortie de TypeScript 7.0 Beta. Si vous n’avez pas suivi le développement de TypeScript 7.0, sachez que cette version est importante car elle repose sur une base entièrement nouvelle. Au cours de l'année écoulée, nous avons porté le code source existant de TypeScript vers Go. Grâce à la combinaison de la vitesse du code natif et du parallélisme en mémoire partagée, TypeScript 7.0 est souvent environ 10 fois plus rapide que TypeScript 6.0. », a déclaré Daniel Rosenwasser, chef de produit principal chez Microsoft.
Microsoft a également profité du lancement de cette version bêta pour affirmer de manière directe que le compilateur était prêt, alors qu'il s'agit d'une version bêta. Dans l'annonce, Daniel Rosenwasser a écrit : « Ne vous laissez pas tromper par la mention « bêta » : vous pouvez probablement commencer à l'utiliser dès maintenant dans votre travail quotidien. Le nouveau code source Go a été méthodiquement porté à partir de notre implémentation existante plutôt que réécrit à partir de zéro, et sa logique de vérification des types est structurellement identique à celle de TypeScript 6.0. Cette parité architecturale garantit que le compilateur continue d'appliquer exactement la même sémantique à laquelle vous êtes déjà habitué. »
Il a ajouté que TypeScript 7.0 a « été évalué à l'aide de l'énorme suite de tests que nous avons constituée au cours de la dernière décennie, et est déjà utilisé dans de nombreuses bases de code comptant plusieurs millions de lignes, tant au sein de Microsoft qu'à l'extérieur. Il est extrêmement stable, hautement compatible et prêt à être mis à l'épreuve dès aujourd'hui dans vos workflows quotidiens et vos pipelines d'intégration continue »
Selon Daniel Rosenwasser, l'équipe de TypeScript collabore depuis plus d'un an avec de nombreuses équipes internes de Microsoft, ainsi qu’avec des équipes d’entreprises telles que Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel, VoidZero et bien d’autres, afin de tester des versions préliminaires de TypeScript 7.0 sur leurs bases de code. Rosenwasser affirme que « les retours ont été extrêmement positifs : de nombreuses équipes ont signalé des gains de vitesse similaires, réduisant considérablement leurs temps de compilation, et ont bénéficié d'une expérience d'édition beaucoup plus légère et fluide. »
Utilisation de TypeScript 7.0 Beta
Pour obtenir TypeScript 7.0 Beta, les utilisateurs peuvent l'installer via npm :
npm install -D @typescript/native-preview@beta
Remarque : le nom du paquet sera éventuellement remplacé par typescript dans une prochaine version.
À partir de là, les utilisateurs peuvent exécuter tsgo à la place de l'exécutable tsc.
1
2
| > npx tsgo --version
Version 7.0.0-beta |
L'exécutable tsgo se comporte de la même manière que tsc de TypeScript 6.0 sur tout le code TypeScript, mais il est bien plus rapide, selon Microsoft.
Pour tester cette expérience d'édition, les utilisateurs peuvent installer l'extension TypeScript Native Preview pour VS Code. Microsoft affirme que la prise en charge par l'éditeur est extrêmement fiable et qu'elle est largement utilisée par de nombreuses équipes depuis plusieurs mois déjà. C'est un moyen simple et fluide d'essayer immédiatement TypeScript 7.0 sur la base de code. Elle repose sur les mêmes fondements que l'expérience en ligne de commande, ce qui permet aux utilisateurs de bénéficier des mêmes améliorations de performances dans leur éditeur que sur la ligne de commande. Microsoft précise par ailleurs qu'elle s'appuie également sur le protocole Language Server Protocol, ce qui facilite son exécution dans la plupart des éditeurs modernes, voire dans des outils tels que Copilot CLI.
Utilisation en parallèle avec TypeScript 6.0
Afin d'aider les utilisateurs à passer de TypeScript 6.0 à TypeScript 7.0, la version bêta est disponible via le paquet @typescript/native-preview en utilisant le point d'entrée tsgo. Cela permet de valider et de comparer facilement les résultats de tsc et de tsgo. Cependant, la version stable de TypeScript 7.0 sera publiée sous le paquet typescript et utilisera le point d'entrée tsc.
De plus, Microsoft indique que même si la version 7.0 Beta est presque prête pour la production, l'équipe TypeScript ne disposera pas d'une API programmatique stable avant au moins plusieurs mois, avec TypeScript 7.1. Dans ce contexte, elle s'est fixé comme priorité de garantir que TypeScript puisse fonctionner en parallèle avec TypeScript 6.0 dans un avenir proche, sans aucun conflit quant à « quel tsc est le bon ? ».
Dans le cadre du processus de transition de la version 6.0 vers la 7.0, Microsoft a publié un nouveau paquet de compatibilité, @typescript/typescript6. Ce paquet expose un nouveau point d'entrée, tsc6, afin que les utilisateurs puissent, si nécessaire, exécuter la prochaine version de TypeScript 7.0 (qui fournira un binaire tsc) en parallèle sans conflit de noms. Il réexportera également l'API TypeScript 6.0, ce qui permettra aux développeurs d'utiliser tsc pour TypeScript 7, tandis que les autres outils pourront continuer à s'appuyer sur la version 6.0.
Étant donné que certains outils, tels que typescript-eslint, s'attendent à ce que les importations soient effectuées directement depuis TypeScript via des dépendances entre pairs, Microsoft recommande d'utiliser des alias npm à cette fin. Les utilisateurs devraient pouvoir exécuter la commande suivante :
npm install -D typescript@npm:@typescript/typescript6
ou modifiez leurs fichiers package.json comme suit :
1
2
3
4
5
| {
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.0",
}
} |
Microsoft indique qu'elle fournira à l'avenir des instructions plus précises concernant l'utilisation d'un tsc alimenté par TS7 parallèlement à un tsc6 alimenté par TS6.
Parallélisation et contrôles
TypeScript 7.0 exécute désormais de nombreuses étapes en parallèle, notamment l'analyse syntaxique, la vérification des types et la génération de code. Certaines de ces étapes, comme l'analyse syntaxique et la génération de code, peuvent généralement être effectuées indépendamment d'un fichier à l'autre. Ainsi, la parallélisation s'adapte automatiquement aux bases de code plus volumineuses avec une surcharge relativement faible. Cependant, Microsoft précise que toutes les étapes d'une compilation TypeScript ne se prêtent pas facilement à la parallélisation.
Parallélisation des vérificateurs de types
Selon l'équipe TypeScript, des étapes, comme la vérification des types, présentent des dépendances plus complexes entre les fichiers. La plupart des fichiers finissent par s'appuyer sur les mêmes informations de type provenant de leurs dépendances et de la portée globale ; par conséquent, exécuter les vérificateurs de types de manière totalement indépendante serait un gaspillage, tant en termes de calcul que de mémoire. D'autre part, la vérification des types s'appuie parfois sur l'ordre relatif des informations dans un programme ; par conséquent, une vérification des types effectuée à partir de zéro doit toujours vérifier les mêmes fichiers dans un ordre identique pour garantir les mêmes résultats.
Pour permettre la parallélisation tout en évitant ces écueils, TypeScript 7.0 crée un nombre fixe de processus de vérification de types, chacun disposant de sa propre vision du monde. Ces processus de vérification de types peuvent finir par dupliquer certaines tâches communes, mais, à partir des mêmes fichiers d'entrée, ils les répartiront toujours de manière identique et produiront les mêmes résultats.
Le nombre par défaut de processus de vérification de types est de 4, mais il peut être configuré à l'aide du nouveau flag --checkers. Les utilisateurs constateront peut-être qu'augmenter ce nombre permet d'accélérer encore davantage les compilations sur des bases de code volumineuses, où les machines disposent généralement de plus de cœurs de processeur, mais cela s'accompagnera généralement d'une augmentation de la consommation de mémoire. De même, sur les machines dotées d'un nombre réduit de cœurs de processeur (par exemple, les serveurs CI) , il peut être préférable de réduire ce nombre afin d'éviter une surcharge inutile.
Microsoft indique que, dans de rares cas, le fait de modifier le nombre de vérificateurs peut faire apparaître des résultats dépendant de l'ordre d'exécution. Le fait de fixer un nombre de vérificateurs pour l'ensemble d'une équipe peut donc contribuer à garantir que tout le monde obtienne les mêmes résultats, mais cette décision relève de la discrétion de chaque équipe.
Parallélisation des compilateurs de références de projet
TypeScript 7.0 permet de paralléliser les compilations au sein d'un même projet, mais il est désormais également possible de compiler plusieurs projets simultanément. Ce comportement peut être configuré à l'aide du nouveau drapeau --builders, qui détermine le nombre de compilateurs de références de projet pouvant s'exécuter en parallèle. Cette fonctionnalité peut s'avérer particulièrement utile pour les monorepos contenant de nombreux projets.
Tout comme l'option --checkers, Microsoft précise qu'augmenter le nombre de processeurs de compilation peut accélérer la compilation, mais cela peut se traduire par une augmentation de la consommation de mémoire. Cela a également un effet multiplicateur avec l'option --checkers ; il est donc important pour l'utilisateur de trouver le bon équilibre pour sa machine et sa base de code. Par exemple, une compilation avec --checkers 4 --builders 4 permet à jusqu'à 16 vérificateurs de types de s'exécuter simultanément, ce qui peut s'avérer excessif.
Cependant, contrairement à l'option --checkers, le fait de modifier le nombre de compilateurs ne devrait pas entraîner de résultats différents ; toutefois, la compilation des références de projet est fondamentalement limitée par le graphe des dépendances des projets (à l'exception de la vérification des types sur les bases de code qui utilisent l'option --isolatedDeclarations et génèrent des fichiers de déclarations syntaxiques séparés).
Mode mono-thread
Microsoft indique que dans certains cas, il peut être utile d'imposer un fonctionnement mono-thread à l'ensemble du compilateur. Cela peut s'avérer utile pour le débogage, pour comparer les performances avec TypeScript 6 et 7, lors de l'orchestration de builds parallèles en externe, ou pour l'exécution dans des environnements aux ressources très limitées. Pour activer le mode monothread, les utilisateurs peuvent recourir au nouveau drapeau --singleThreaded. Cela limitera non seulement le nombre de workers chargés de la vérification des types à 1, mais garantira également que l'analyse et l'émission s'effectuent dans un seul thread.
Mises à jour depuis la version 5.x et nouveaux comportements à partir de la version 6.0
TypeScript 7.0 est conçu pour être compatible avec le système de vérification des types et le comportement en ligne de commande de TypeScript 6.0. Tout code TypeScript qui se compile sans erreur avec TypeScript 6.0 (avec le drapeau stableTypeOrdering activé et sans le drapeau ignoreDeprecations défini) devrait se compiler de la même manière dans TypeScript 7.0.
TypeScript 7.0 reprend les nouvelles valeurs par défaut de la version 6.0 et génère des erreurs critiques en cas d'utilisation de drapeaux ou de constructions obsolètes dans TypeScript 6.0. Microsoft encourage les développeurs à adopter TypeScript 6.0 afin de faciliter la transition vers TypeScript 7.0.
En résumé, les principaux changements apportés aux paramètres par défaut sont les suivants :
- strict est défini sur true par défaut.
- module est défini par défaut sur esnext.
- target est défini par défaut sur la version stable d'ECMAScript immédiatement antérieure à esnext.
- noUncheckedSideEffectImports est défini sur true par défaut.
- libReplacement est défini sur false par défaut
- stableTypeOrdering est défini sur true par défaut et ne peut pas être désactivé.
- rootDir est désormais défini par défaut sur ./, et les répertoires de sources internes doivent être spécifiés explicitement.
- types est désormais défini par défaut sur [], et l'ancien comportement peut être rétabli en le définissant sur ["*"].
L'équipe TypeScript estime que les modifications apportées à rootDir et types sont peut-être les plus « surprenantes », mais qu'elles peuvent être facilement gérées. Pour les projets dans lesquels le fichier tsconfig.json se trouve en dehors d'un répertoire tel que src, il suffira d'inclure rootDir pour conserver la même structure de répertoires.
1
2
3
4
5
6
7
| {
"compilerOptions": {
// ...
+ "rootDir": "./src"
},
"include": ["./src"]
} |
En raison du changement de types, les projets qui dépendent de déclarations globales spécifiques devront les mentionner explicitement. Par exemple :
1
2
3
4
5
6
| {
"compilerOptions": {
// Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)
+ "types": ["node", "jest"]
}
} |
Les dépréciations qui sont désormais traitées comme des erreurs critiques sans comportement no-op sont les suivants :
- target : es5 n'est plus pris en charge.
- downlevelIteration n'est plus pris en charge.
- moduleResolution : node/node10 ne sont plus pris en charge ; il est recommandé d'utiliser nodenext et bundler à la place.
- module : amd, umd, systemjs, none ne sont plus pris en charge ; il est recommandé d'utiliser esnext ou preserve en conjonction avec des bundlers ou la résolution de modules basée sur le navigateur.
- baseUrl n'est plus pris en charge, et paths peut être mis à jour pour être relatifs à la racine du projet au lieu de baseUrl.
- moduleResolution: classic n'est plus pris en charge ; il est recommandé d'utiliser bundler ou nodenext à la place.
- esModuleInterop et allowSyntheticDefaultImports ne peuvent plus être définis sur false.
- alwaysStrict est considéré comme true et ne peut plus être défini sur false.
- Le mot-clé module ne peut pas être utilisé dans les déclarations d'espace de noms.
- Le mot-clé asserts ne peut pas être utilisé sur les importations ; il faut utiliser le mot-clé with à la place (pour s'aligner sur les développements de la syntaxe de l'attribut import d'ECMAScript).
- Les directives /// <reference no-default-lib /> ne sont plus respectées sous skipDefaultLibCheck.
- Les builds en ligne de commande ne peuvent pas accepter de chemins de fichiers lorsque le répertoire courant contient un fichier tsconfig.json, sauf passage explicite du drapeau --ignoreConfig.
Différences au niveau de JavaScript
Lors du portage du code existant, Microsoft en a également profité pour revoir le fonctionnement de sa prise en charge de JavaScript.
À l'origine, TypeScript prenait en charge les fichiers JavaScript en utilisant les commentaires JSDoc et en reconnaissant certains modèles de code à des fins d'analyse et d'inférence de types. La plupart du temps, cela reposait sur des modèles de codage courants, mais parfois, cela reposait sur tout ce que les développeurs pouvaient écrire et que Closure et l'outil de génération de documentation JSDoc étaient capables de comprendre. Bien que cette approche ait été utile pour les développeurs disposant de bases de code JSDoc rédigées de manière informelle, Microsoft indique qu'elle nécessitait un certain nombre de compromis et de cas particuliers pour fonctionner correctement, et s'écartait à plusieurs égards de l'analyse effectuée par TypeScript dans les fichiers .ts.
Dans TypeScript 7.0, Microsoft a remanié la prise en charge de JavaScript afin de la rendre plus cohérente avec la manière dont sont analysés les fichiers TypeScript. Voici quelques-unes des différences :
- Les valeurs ne peuvent pas être utilisées là où des types sont attendus ; à la place, écrivez typeof someValue.
- @enum n'est plus reconnu ; créez un @typedef sur (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].
- Un ? seul n'est plus utilisable comme type ; utilisez plutôt any.
- @class ne transforme pas une fonction en constructeur ; utilisez plutôt une déclaration class.
- Le suffixe ! n'est pas pris en charge – utilisez simplement T.
- Les noms de types doivent être définis dans une balise @typedef (c'est-à-dire /** @typedef {T} TypeAliasName */), et non à côté d'un identifiant (c'est-à-dire /** @typedef {T} */ TypeAliasName;).
- La syntaxe des fonctions de type fermeture (par exemple function(string): void) n'est plus prise en charge – utilisez plutôt les raccourcis TypeScript (par exemple (s: string) => void).
De plus, certaines pratiques JavaScript, comme l'aliasing de `this` et la réaffectation de l'intégralité du prototype d'une fonction, ne font plus l'objet d'un traitement particulier.
Expérience dans l'éditeur
Les améliorations apportées aux performances de TypeScript 7.0 ne se limitent pas à l'utilisation en ligne de commande : elles s'étendent également à l'expérience dans l'éditeur. L'extension « TypeScript Native Preview » pour VS Code permet d'essayer TypeScript 7.0 en toute transparence dans l'éditeur.
« Depuis son lancement, nous avons ajouté des fonctionnalités qui faisaient défaut, telles que l'importation automatique, les survols extensibles, les astuces intégrées, les loupes de code, l'accès direct à la définition dans le code source, l'édition liée JSX et la complétion de balises, entre autres. De plus, nous avons entièrement repensé une grande partie de notre infrastructure de tests et de diagnostics afin de garantir un niveau de qualité élevé », a déclaré Daniel Rosenwasser. « Cette extension reprend la plupart des paramètres de configuration de l'extension TypeScript intégrée à Visual Studio Code, ainsi que la plupart de ses fonctionnalités. Même si certaines fonctionnalités sont encore en cours de développement (comme la mise en évidence sémantique, des commandes plus spécifiques pour la gestion des importations, etc.), l'extension est déjà puissante, stable et rapide. »
Travaux à venir
Au cours des prochaines semaines, Microsoft prévoit de déployer une implémentation plus efficace de l'option --watch et d'atteindre la parité en matière de génération de fichiers de déclaration à partir de fichiers JavaScript. L'entreprise travaillera également sur des lacunes mineures au niveau des fonctionnalités de l'éditeur, telles que la recherche de références de fichiers depuis l'explorateur de fichiers, ainsi que sur la mise en avant de commandes plus précises comme « Trier les importations » et « Supprimer les importations inutilisées », en lieu et place de la commande plus générale « Organiser les importations ».
Microsoft indique également qu'elle développera une API programmatique stable pour TypeScript 7.1 ou une version ultérieure, qu'elle améliorera son infrastructure de tests en conditions réelles et qu'elle prendra en compte les commentaires reçus.
« La version bêta de TypeScript 7.0 étant désormais disponible, l'équipe se concentre sur la correction des bogues, les travaux de compatibilité, la mise au point de l'éditeur et l'amélioration des performances en vue d'une version stable. Nous prévoyons actuellement de publier TypeScript 7.0 dans les deux prochains mois, avec une version candidate disponible quelques semaines auparavant. La version candidate marquera, selon nos prévisions, la finalisation du comportement de TypeScript 7 ; les modifications apportées par la suite porteront principalement sur la correction des régressions critiques », a conclu Daniel Rosenwasser.
Source : Microsoft
Et vous ?
Quel est votre avis sur le sujet ?
Que pensez-vous des nouveautés proposées par cette version de TypeScript ? Les trouvez-vous utiles et intéressantes ?
Voir aussi :
Microsoft annonce TypeScript 6.0 apportant des améliorations aux fonctions sensibles au contexte, la prise en charge des importations de sous-chemins et des changements pour préparer TypeScript 7.0
Microsoft annonce la version candidate (RC) de TypeScript 5.9 apportant des mise à jour à tsc --init ainsi que la prise en charge de import defer et de --module node20
TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates
Microsoft annonce la version bêta de TypeScript 7.0, basée sur le langage Go
Répondre avec citation
Partager