Microsoft annonce la version bêta de TypeScript 7.0, basée sur le langage Go
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 :
Code:
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.
Code:
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 :
Code:
npm install -D typescript@npm:@typescript/typescript6
ou modifiez leurs fichiers package.json comme suit :
Code:
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.
Code:
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 :
Code:
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 ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous des nouveautés proposées par cette version de TypeScript ? Les trouvez-vous utiles et intéressantes ?
Voir aussi :
:fleche: 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
:fleche: 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
:fleche: TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates
Microsoft annonce la version Release Candidate de TypeScript 7.0, basée sur le langage Go
Microsoft annonce la version Release Candidate de TypeScript 7.0, basée sur le langage Go, permettant d'exécuter de nombreuses étapes en parallèle, notamment l'analyse syntaxique et la vérification des types
Microsoft annonce la sortie de la version Release Candidate de TypeScript 7.0. La nouvelle base de code Go a été méthodiquement portée à partir de l'implémentation existante plutôt que réécrite à partir de zéro, et sa logique de vérification des types est structurellement identique à celle de TypeScript 6.0. Même si la version 7.0 RC est presque prête pour la production, ils ne disposeront pas d’une API programmatique stable avant au moins plusieurs mois, avec la sortie de TypeScript 7.1. Dans ce contexte, l'équipe TypeScript donne la priorité à la garantie que TypeScript puisse fonctionner en parallèle avec TypeScript 6.0 dans un avenir proche.
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.
En avril 2026, 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é. 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.
Récemment, Microsoft annonce la sortie de la version Release Candidate de TypeScript 7.0. La nouvelle base de code Go a été méthodiquement portée à partir de l'implémentation existante plutôt que réécrite à 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é. TypeScript 7.0 a été évalué à l’aide de l’énorme suite de tests 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 stable, compatible et prêt à être mis à l’épreuve dès dans vos workflows quotidiens et vos pipelines d’intégration continue.
Depuis plus d’un an, l'équipe TypeScript collabore 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 les versions préliminaires de TypeScript 7.0 sur leurs bases de code. Les retours ont été 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 RC
Pour obtenir TypeScript 7.0 RC, vous pouvez l’installer via npm :
Code:
npm install -D typescript@rc
À partir de là, vous pouvez exécuter tsc comme avec n’importe quelle version précédente de TypeScript, et vous devriez obtenir les mêmes résultats qu’auparavant – mais beaucoup plus rapidement !
Code:
1
2
| > npx tsc --version
Version 7.0.1-rc |
Pour tester l’expérience d’édition, vous pouvez installer l’extension TypeScript Native Preview pour VS Code. La prise en charge par l’éditeur est extrêmement fiable et est largement utilisée par de nombreuses équipes depuis plusieurs mois déjà. C’est un moyen simple et fluide de tester immédiatement TypeScript 7.0 sur votre base de code. Elle repose sur les mêmes fondements que l’expérience en ligne de commande, vous bénéficiez donc des mêmes gains de performances dans votre éditeur que sur la ligne de commande. Il est notamment important de noter qu’elle s’appuie sur le protocole LSP (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
Même si la version 7.0 RC est presque prête pour la production, ils ne disposeront pas d’une API programmatique stable avant au moins plusieurs mois, avec la sortie de TypeScript 7.1. Dans ce contexte, l'équipe TypeScript donne la priorité à la garantie que TypeScript puisse fonctionner en parallèle avec TypeScript 6.0 dans un avenir proche, sans aucun conflit du type « quel tsc est lequel ? ».
Dans le cadre du processus de transition entre les versions 6.0 et 7.0, ils ont publié un nouveau package de compatibilité, @typescript/typescript6. Ce package fournit un exécutable nommé tsc6, afin que, si nécessaire, vous puissiez installer TypeScript 7.0 (qui intègre son propre binaire tsc) en parallèle sans conflit de noms. Le nouveau paquet réexporte également l’API de TypeScript 6.0, ce qui vous permet d’utiliser tsc pour TypeScript 7, tandis que d’autres outils peuvent continuer à s’appuyer sur la version 6.0.
Étant donné que certains outils, tels que typescript-eslint, s’attendent à importer directement depuis TypeScript via des dépendances de pair, il est recommandé d’utiliser des alias npm. Vous devriez pouvoir exécuter la commande suivante :
Code:
npm install -D typescript@npm:@typescript/typescript6
ou modifier votre fichier package.json comme suit :
Code:
1
2
3
4
5
| {
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.0",
}
} |
Notez que cette procédure ne vous laissera qu’un exécutable tsc6. Pour obtenir le tsc de la version 7.0, vous pouvez ajouter un autre alias pour TypeScript 7 ; npx tsc fonctionnera alors directement avec la version 7.0 :
Code:
1
2
3
4
5
6
| {
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.0",
"typescript-7": "npm:typescript@rc",
}
} |
Versions « nightly »
Les versions « nightly » de TypeScript 7 sont actuellement toujours publiées sous le paquet @typescript/native-preview sur npm, et peuvent être installées via
Code:
npm install -D @typescript/native-preview
Le binaire fourni par ce paquet s’appelle toujours tsgo. Une fois que TypeScript 7 aura été publié avec la dernière balise sur npm, ils prévoient que toutes les versions stables, les préversions majeures et les versions « nightly » seront publiées sous le paquet typescript sur npm.
Voici les principales améliorations présentées par l'équipe de TypeScript :
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 de manière indépendante d’un fichier à l’autre. Ainsi, la parallélisation s’adapte automatiquement aux bases de code plus volumineuses avec une surcharge relativement faible. Cependant, toutes les étapes d’une compilation TypeScript ne se prêtent pas facilement à la parallélisation.
Parallélisation des vérificateurs
D’autres é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 ; ainsi, une vérification des types effectuée à partir de zéro doit toujours analyser les mêmes fichiers dans un ordre identique pour garantir des résultats identiques.
Pour permettre la parallélisation tout en évitant ces écueils, TypeScript 7.0 crée un nombre fixe de « workers » de vérification de types, chacun disposant de sa propre vision du monde. Ces « workers » 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 nouvel indicateur --checkers. Vous constaterez peut-être qu’augmenter ce nombre peut accélérer davantage les compilations sur des bases de code plus volumineuses, où les machines disposent généralement de plus de cœurs de processeur, mais cela se fera généralement au prix d’une utilisation accrue de la mémoire. De même, les machines disposant de moins de cœurs de processeur et de moins de mémoire (par exemple, les exécuteurs d’intégration continue) peuvent avoir intérêt à réduire ce nombre pour éviter une surcharge inutile ou accidentelle.
Dans de rares cas, la variation du nombre de --checkers peut faire apparaître des résultats dépendants de l’ordre d’exécution. Spécifier un nombre fixe de vérificateurs dans tous les environnements de compilation peut aider à garantir que tout le monde obtient les mêmes résultats, mais cela reste à la discrétion de chaque équipe.
Parallélisation des générateurs de référence de projet
TypeScript 7.0 permet de paralléliser les compilations au sein d’un même projet, mais il peut désormais également compiler plusieurs projets simultanément. Ce comportement peut être configuré à l’aide du nouvel indicateur --builders, qui contrôle le nombre de générateurs de référence de projet parallèles pouvant s’exécuter simultanément. Cela peut s’avérer particulièrement utile pour les monorepos contenant de nombreux projets.
Tout comme avec --checkers, augmenter le nombre de générateurs peut accélérer les compilations, mais peut se faire au prix d’une consommation de mémoire accrue. Cela a également un effet multiplicateur avec --checkers ; il est donc important de trouver le bon équilibre pour votre machine et votre 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.
Contrairement à --checkers, la variation du nombre de générateurs ne devrait pas produire de résultats différents ; cependant, la compilation des références de projet est fondamentalement limitée par le graphe de dépendances des projets (à l’exception de la vérification de types sur les bases de code qui exploitent --isolatedDeclarations et génèrent un fichier de déclaration syntaxique séparé).
Mode mono-thread
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 entre TypeScript 6 et 7, lors de l’orchestration externe de compilations parallèles, ou pour l’exécution dans des environnements aux ressources très limitées. Pour activer le mode mono-thread, vous pouvez utiliser le nouvel indicateur --singleThreaded. Cela limitera non seulement le nombre de workers de vérification de types à 1, mais garantira également que l’analyse syntaxique et la génération de fichiers s’effectuent dans un seul thread.
Mode --watch amélioré
Il convient de souligner la refonte du mode --watch dans TypeScript 7. Le mode --watch repose désormais sur une nouvelle base dérivée du système de surveillance de fichiers du bundler Parcel, qui offre des capacités de surveillance de fichiers multiplateformes efficaces et stables.
Lorsque notre équipe s’est attelée à porter notre logique de surveillance de fichiers, nous avons rencontré quelques difficultés liées à la surveillance multiplateforme en Go. La bibliothèque standard ne fournit pas d’API intégrée de surveillance des fichiers, et les bibliothèques tierces existantes que nous avons explorées présentaient divers problèmes de stabilité, de performances, de prise en charge multiplateforme ou d’intégration avec les outils de build. Nous avons pu mettre au point des solutions reposant sur des interrogations périodiques pour détecter les modifications de fichiers, ce qui fonctionnait globalement sur tous les systèmes d’exploitation ; cependant, cela s’avérait très gourmand en ressources, en particulier pour les projets à grande échelle comportant de nombreuses dépendances dans node_modules. Même avec des stratégies de planification dynamiques, nous avons constaté que les solutions basées uniquement sur l’interrogation étaient trop gourmandes en ressources pour une utilisation courante.
Depuis de nombreuses années, Visual Studio Code s’appuie sur @parcel/watcher, et ces dernières années, TypeScript dans VS Code a indirectement tiré parti de ses capacités de surveillance de fichiers. Bien que cela semblait prometteur, l’un des problèmes que nous rencontrions avec le watcher de Parcel est qu’il est écrit en C++ et nécessite donc une chaîne d’outils C++ complète pour sa compilation. Compte tenu de notre expérience positive avec le watcher de Parcel dans VS Code, nous avons exploré la possibilité de le porter en Go à l’aide de quelques shims d’assemblage minimaux afin d’éviter d’introduire une nouvelle dépendance à une chaîne d’outils.
Cette exploration a été couronnée de succès : ce qui avait commencé comme une traduction très directe du C++ vers Go a été affiné pour devenir un code idiomatique en Go qui continue de passer avec succès la suite de tests portée. Le « watcher » est un paquet autonome qui nous a permis de maintenir une séparation claire des préoccupations entre ce que nous souhaitons surveiller et pourquoi. Nous constatons désormais des améliorations significatives en termes de ressources en mode --watch sur toutes les plateformes, et avons reçu des retours positifs de la part des premiers utilisateurs de TypeScript 7.
Nous tenons à remercier Devon Govett, dont le travail sur Parcel a apporté d’immenses avantages tant au projet Visual Studio Code qu’à celui de TypeScript. Nous espérons que ce portage offrira, à terme, de nouvelles opportunités et des perspectives pour le code source original du « watcher » de Parcel.
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 la vérification des types et le comportement en ligne de commande de TypeScript 6.0. Pratiquement tout code TypeScript qui se compile sans erreur avec TypeScript 6.0 (avec le drapeau stableTypeOrdering activé et sans aucun drapeau ignoreDeprecations défini) devrait se compiler de la même manière dans TypeScript 7.0.
Cela dit, TypeScript 7.0 adopte les nouvelles valeurs par défaut de la version 6.0 et génère des erreurs fatales en cas d’utilisation de drapeaux ou de constructions obsolètes dans TypeScript 6.0. Ce point est important, car la version 6.0 est encore relativement récente et de nombreux projets devront s’adapter à ses nouveaux comportements. Nous encourageons les développeurs à adopter TypeScript 6.0 afin de faciliter la transition vers TypeScript 7.0. Vous pouvez également consulter l’article de blog consacré à la sortie de TypeScript 6.0 pour plus de détails sur ces dépréciations.
En bref, les changements notables 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 actuelle d’ECMAScript précédant immédiatement 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 source internes doivent être explicitement définis.
- types est désormais défini par défaut sur [], et l’ancien comportement peut être rétabli en le définissant sur ["*"].
Nous pensons que les modifications apportées à rootDir et types sont peut-être les plus « surprenantes », mais elles peuvent être facilement gérées. Les projets dans lesquels le fichier tsconfig.json se trouve en dehors d’un répertoire tel que src devront simplement inclure rootDir pour conserver la même structure de répertoires.
Code:
1
2
3
4
5
6
7
| {
"compilerOptions": {
// ...
+ "rootDir": "./src"
},
"include": ["./src"]
} |
En ce qui concerne la modification de types, les projets qui dépendent de déclarations globales spécifiques devront les énumérer explicitement. Par exemple :
Code:
1
2
3
4
5
6
| {
"compilerOptions": {
// Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)
+ "types": ["node", "jest"]
}
} |
Les éléments obsolètes qui sont désormais considérés comme des erreurs graves sans conséquence 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 association avec des bundlers ou la résolution de modules basée sur le navigateur.
- baseUrl n’est plus pris en charge, et les paths peuvent être mis à jour pour être relatifs à la racine du projet plutôt qu’à baseUrl.
- moduleResolution : classic n’est plus pris en charge ; il est recommandé de le remplacer par bundler ou nodenext.
- esModuleInterop et allowSyntheticDefaultImports ne peuvent pas ê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 à la place le mot-clé with (afin de s’aligner sur les évolutions de la syntaxe de l’attribut import d’ECMAScript).
- Les directives /// <reference no-default-lib /> ne sont plus respectées lorsque skipDefaultLibCheck est activé.
- Les compilations en ligne de commande ne peuvent pas prendre en compte les chemins d’accès aux fichiers lorsque le répertoire courant contient un fichier tsconfig.json, sauf si le drapeau explicite --ignoreConfig est passé.
Les types de littéraux de modèle préservent désormais les points de code Unicode
TypeScript 7.0 traite désormais les points de code Unicode de manière plus naturelle lors de l’inférence à partir des types de littéraux de modèle. Par exemple :
Code:
1
2
3
4
5
6
| type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"abc">;
// ^
// In 7.0: ["", "abc"]
// Previously: ["\ud83d", "\ude00abc"] |
Auparavant, TypeScript suivait ici le comportement d’indexation UTF-16 de JavaScript et divisait "😀" en deux moitiés formant une paire de substituts (\ud83d et \ude00). Cela était techniquement cohérent avec l’indexation en JavaScript (par exemple, le type Head déduit était égal à " 😀abc"[0]), mais ce n’était généralement pas ce que les utilisateurs souhaitaient, et cela pouvait produire des types de littéraux de chaîne contenant des caractères de substitution non appariés qui n’ont pas de sens sémantique.
Il s’agit d’un changement rompant pour la manipulation de chaînes au niveau des types qui modélisait intentionnellement les unités de code UTF-16, comme certaines utilitaires de longueur de chaîne. En pratique, nous nous attendons à ce que ce nouveau comportement soit plus utile et moins surprenant : l’inférence des littéraux de modèle suit désormais la même intuition que l’itération d’une chaîne avec for...of ou son étalement avec [...str], où "😀" est traité comme une seule unité.
Différences par rapport à JavaScript
Lors du portage de la base de code existante, nous en avons également profité pour revoir le fonctionnement de notre 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 pour l’analyse et l’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 peu rigoureuse, 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, nous avons remanié notre prise en charge de JavaScript afin qu’elle soit plus cohérente avec la manière dont nous analysons les fichiers TypeScript. Voici quelques-unes des différences :
- Les valeurs ne peuvent pas être utilisées là où des types sont attendus – écrivez plutôt typeof someValue.
- @enum n’est plus reconnu spécifiquement – créez un @typedef sur (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].
- Un ? isolé n’est plus utilisable comme type – utilisez plutôt any.
- @class ne transforme pas une fonction en constructeur – utilisez plutôt une déclaration de classe.
- Le suffixe ! n’est pas pris en charge – utilisez simplement T.
- Les noms de types doivent être définis à l’intérieur d’une balise @typedef (par exemple : /** @typedef {T} TypeAliasName */), et non à côté d’un identifiant (par exemple : /** @typedef {T} */ TypeAliasName;).
- La syntaxe des fonctions de type « closure » (par exemple function(string): void) n’est plus prise en charge – utilisez plutôt les raccourcis TypeScript (par exemple (s: string) => void).
De plus, certains modèles 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.
Bien qu’une partie de notre prise en charge de JS soit en pleine évolution, nous avons mis à jour ce fichier CHANGES.md afin de détailler plus précisément les différences entre TypeScript 6.0 et 7.0.
Expérience dans l’éditeur
Les améliorations de 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. Pour les utilisateurs de VS Code, l’extension « TypeScript Native Preview » offre un moyen simple d’essayer TypeScript 7.0 dans votre éditeur, et elle est désormais largement utilisée. Pour les utilisateurs de Visual Studio, la dernière version de l’éditeur activera automatiquement TypeScript 7 en fonction de votre espace de travail. Bien entendu, TypeScript 7 devrait fonctionner parfaitement dans n’importe quel éditeur de votre choix. La nouvelle infrastructure repose sur le protocole LSP (Language Server Protocol) et est capable d’exploiter plusieurs threads pour traiter les requêtes simultanées aussi rapidement que possible.
Depuis son lancement, nous avons ajouté des fonctionnalités qui manquaient, telles que les importations automatiques, les survols extensibles, les astuces intégrées, les « code lenses », la fonction « aller à la définition source », l’édition liée à JSX et la complétion des balises, entre autres. Les fonctionnalités manquantes de la version bêta de TypeScript 7.0, telles que la mise en évidence sémantique, le « tri des importations », la « suppression des importations inutilisées », et bien d’autres encore, sont désormais disponibles.
De plus, nous avons continué à améliorer les performances et la stabilité au cours des derniers mois. Nous avons refondu une grande partie de notre infrastructure de tests et de diagnostics afin de garantir un niveau de qualité élevé, ce qui nous permet de soumettre le serveur de langage à des tests de fuzz sur les principales bases de code TypeScript et JavaScript disponibles sur GitHub. D’après nos analyses de données, nous estimons que TypeScript 7 a en réalité réduit de plus de 20 fois le nombre d’échecs des commandes du serveur de langage par rapport à TypeScript 6.0.
Cette extension respecte 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.
Source : Annonce TypeScript 7.0 RC
Et vous ?
:fleche: Pensez-vous que cette version est crédible ou pertinente ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: 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
:fleche: Un TypeScript 10x plus rapide : Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, présente un nouveau portage de TypeScript, qui offrira aux développeurs un outil de haute performance
:fleche: TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates
3 pièce(s) jointe(s)
Microsoft annonce la disponibilité de TypeScript 7.0
Microsoft annonce la disponibilité de TypeScript 7.0, « un portage natif 10 fois plus rapide développé en Go » selon Microsoft, permettant d'effectuer de nombreuses étapes en parallèle
Microsoft annonce la disponibilité générale de TypeScript 7, un portage natif de TypeScript 10 fois plus rapide en Go. La principale différence réside dans le fait qu’avec cette nouvelle base de code, TypeScript 7 offre la vitesse du code natif, le multithreading en mémoire partagée et un certain nombre de nouvelles optimisations qui permettent généralement des gains de vitesse compris entre 8 et 12 fois lors des compilations complètes. TypeScript 7.0 effectue désormais de nombreuses étapes en parallèle, notamment l’analyse syntaxique, la vérification des types et la génération de code. TypeScript 7.0 peut paralléliser les compilations au sein d’un même projet, mais il est désormais également capable de compiler plusieurs projets simultanément. Il convient de souligner que les workflows utilisant Vue, MDX, Astro, Svelte et d’autres frameworks ne pourront probablement pas encore tirer parti de TypeScript 7. De même, la vérification de types spécialisée au sein de modèles tels que ceux d’Angular n’utilisera probablement pas non plus TypeScript 7.
TypeScript (TS) est un langage de programmation de haut niveau qui ajoute au JavaScript un typage statique avec des annotations de type facultatives. Il est conçu pour le développement d’applications de grande envergure. Il est transcompilé en JavaScript. Il est développé par Microsoft en tant que logiciel libre et open source, distribué sous licence Apache 2.0. TypeScript peut être utilisé pour développer des applications JavaScript destinées à être exécutées aussi bien côté client que côté serveur (comme avec React.js, Node.js, Deno ou Bun). Plusieurs options sont disponibles pour la compilation. Il est possible d’utiliser le compilateur TypeScript par défaut,[8] ou d’invoquer le compilateur Babel pour convertir TypeScript en JavaScript.
Go est un langage de programmation de haut niveau et à usage général, statiquement typé et compilé. Il est réputé pour la simplicité de sa syntaxe et l’efficacité du développement qu’il permet grâce à l’intégration d’une vaste bibliothèque standard répondant à de nombreux besoins des projets courants. Il a été conçu chez Google en 2007 par Robert Griesemer, Rob Pike et Ken Thompson, puis annoncé publiquement en novembre 2009. Sa syntaxe est similaire à celle du C, mais il dispose également d’un ramasse-miettes, d’un typage structurel et d’une concurrence de type CSP. On l’appelle souvent « Golang » pour éviter toute ambiguïté et en raison de son ancien nom de domaine, golang.org ; cependant, son nom officiel est « Go ».
Le 11 mars 2025, Microsoft a annoncé une réécriture de son langage de programmation TypeScript en le dotant d'un compilateur et d'un ensemble d'outils natifs. Cet effort vise à résoudre les problèmes de performance, en particulier dans les grandes bases de code, en portant le compilateur TypeScript existant de TypeScript/JavaScript au langage natif, Go. Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, affirmait lors de l'annonce : « L'implémentation native améliorera considérablement le démarrage de l'éditeur, divisera par 10 la plupart des temps de construction et réduira substantiellement l'utilisation de la mémoire. »
En juin 2026, Microsoft a annoncé la sortie de la version Release Candidate de TypeScript 7.0. La nouvelle base de code Go a été méthodiquement portée à partir de l'implémentation existante plutôt que réécrite à partir de zéro, et sa logique de vérification des types est structurellement identique à celle de TypeScript 6.0. Même si la version 7.0 RC est presque prête pour la production, ils ne disposeront pas d’une API programmatique stable avant au moins plusieurs mois, avec la sortie de TypeScript 7.1. Dans ce contexte, l'équipe TypeScript donne la priorité à la garantie que TypeScript puisse fonctionner en parallèle avec TypeScript 6.0 dans un avenir proche.
Récemment, Microsoft annonce la disponibilité générale de TypeScript 7, un portage natif de TypeScript 10 fois plus rapide. Depuis ses débuts, TypeScript s’est donné pour mission d’offrir un JavaScript évolutif. En apportant une vérification de types stricte et une suite d’outils complète à l’univers JavaScript, TypeScript a permis de développer des applications non triviales et de haute qualité sur toutes les plateformes.
L'équipe de TypeScript déclare pour l'annonce : « L’année dernière, notre équipe a dévoilé la prochaine étape de TypeScript en matière d’évolutivité : rendre chaque composante de la suite d’outils un ordre de grandeur plus rapide. La mission consistait à réaliser un portage natif de TypeScript écrit en Go, capable de tirer pleinement parti du matériel moderne. Ce portage a été effectué de la manière la plus fidèle possible, en écrivant du nouveau code tout en conservant la structure et la logique de la base de code d’origine afin de garantir la cohérence et la compatibilité des résultats entre les deux compilateurs. La principale différence réside dans le fait qu’avec cette nouvelle base de code, TypeScript 7 offre la vitesse du code natif, le multithreading en mémoire partagée et un certain nombre de nouvelles optimisations qui permettent généralement des gains de vitesse compris entre 8 et 12 fois lors des compilations complètes.»
Comme pour toute autre version, TypeScript 7 est disponible via npm :
Code:
npm install -D typescript
Cela vous permettra d’obtenir le nouvel exécutable tsc dans votre espace de travail (que vous pouvez lancer via npx tsc). Bien sûr, une grande partie de l’expérience TypeScript repose également sur la prise en charge par les éditeurs. Votre éditeur de code préféré devrait facilement prendre en charge TypeScript 7 grâce à sa nouvelle compatibilité avec le protocole LSP (Language Server Protocol) et à ses nouvelles améliorations en matière de vitesse et de multithreading. Que vous utilisiez VS Code, Visual Studio, WebStorm ou tout autre éditeur moderne, TypeScript 7 devrait fonctionner à merveille. Il suffit de consulter la documentation de votre éditeur : par exemple, VS Code propose une extension dédiée à TypeScript 7 que vous pouvez utiliser dès aujourd’hui, et Visual Studio activera automatiquement TypeScript 7 en fonction de votre espace de travail.
Voici l'annonce de TypeScript 7.0 :
Annonce de TypeScript 7.0
Que signifie un TypeScript plus rapide ?
Un TypeScript plus rapide, cela semble formidable en théorie, mais qu’est-ce que cela signifie concrètement ? Il peut être utile de réfléchir aux différentes étapes du développement où TypeScript intervient.
Une journée de développement type peut consister à ouvrir votre éditeur, à ouvrir un fichier TypeScript et à lancer une opération telle que la recherche de toutes les références dans vos projets. Ensuite, lorsque vous commencez à apporter des modifications, vous vous attendez peut-être à ce que des suggestions d’autocomplétion s’affichent et à voir apparaître des ondulations rouges au fur et à mesure que vous effectuez vos modifications. Lorsque vous (et, plus récemment, peut-être un agent IA) étiez prêt à compiler votre projet, vous lanciez tsc, vérifiiez la sortie à la recherche d’erreurs, puis exécutiez d’une manière ou d’une autre le code généré.
Un TypeScript plus rapide signifie que chaque étape ci-dessus est optimisée. L’attente du chargement complet de votre projet par votre éditeur vous semblera instantanée. Les délais liés à la recherche de toutes les références, à l’autocomplétion et aux diagnostics ne devraient prendre qu’une fraction du temps qu’ils prenaient auparavant. Et lorsque vous exécuterez tsc, peut-être en mode --watch, vous pourrez raccourcir votre boucle de rétroaction et itérer plus rapidement que jamais.
Vous pouvez constater cela sur des projets concrets. En effet, vous pouvez essayer vous-même de comparer quelques projets open source. Voici les temps de compilation obtenus en exécutant TypeScript 6 et 7 sur des bases de code open source assez volumineuses.
TypeScript 7 affiche généralement de meilleures performances tout en nécessitant moins de mémoire totale sur l’ensemble d’une compilation.
Bien sûr, l’expérience ne se limite pas à la compilation complète. Sur le même ordinateur, l’ouverture d’un fichier contenant une erreur dans la base de code de VS Code prenait auparavant environ 17,5 secondes entre le moment où vous ouvriez l’éditeur et celui où vous voyiez la première erreur. Avec TypeScript 7, ce délai est inférieur à 1,3 seconde – soit plus de 13 fois plus rapide.
Éprouvé en conditions réelles et prêt pour la production
Le projet TypeScript comprend des dizaines de milliers de tests développés depuis plus d’une décennie, qui s’exécutent à chaque commit sur notre branche principale. Ils ont permis de garantir la stabilité et la fiabilité de chacune de nos versions.
Mais TypeScript 7 n’est pas une version comme les autres. Au-delà de notre suite de tests, nous avons mobilisé diverses ressources pour nous assurer que TypeScript 7 est suffisamment robuste pour une utilisation en production.
Au cours de l’année écoulée, nous avons collaboré avec de nombreuses équipes de grande envergure, tant en interne qu’en externe, afin de tester TypeScript 7 sur des bases de code réelles. Les résultats se sont révélés extrêmement positifs : des entreprises entières ont indiqué que TypeScript 7 s’était montré stable, rapide et facile à adopter. Par exemple, l’équipe de VS Code a récemment mis en avant son expérience avec les versions préliminaires de TypeScript 7, qui lui ont permis d’accélérer son cycle de développement. Nous avons également collaboré avec des équipes Microsoft telles que Loop, Office, PowerBI, Teams et Xbox afin de nous assurer que TypeScript est prêt à prendre en charge les bases de code les plus volumineuses. De même, des entreprises telles que Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero et bien d’autres ont collaboré avec nous pour tester TypeScript 7 sur leurs bases de code et nous ont fait part de leurs retours afin de l’améliorer.
De plus, nous avons refondu une grande partie de notre infrastructure de test globale pour qu’elle fonctionne avec TypeScript 7. TypeScript 6 et les versions antérieures proposaient des tests automatisés et à la demande pour les projets TypeScript et JavaScript sur GitHub, afin de détecter les régressions dans le compilateur et le service de langage. Ces mêmes tests sont de retour et s’exécutent désormais sur TypeScript 7, identifiant des problèmes dans de véritables bases de code afin que nous puissions repérer les lacunes de notre suite de tests principale et offrir une meilleure expérience.
La combinaison des retours d’expérience explicites, des rapports de plantage automatisés et des tests intensifs a permis d’améliorer sensiblement la qualité. En effet, l’analyse de nos données nous a montré que le nouveau serveur de langage de TypeScript 7.0 a réduit de plus de 80 % les échecs des commandes du serveur de langage et de plus de 60 % les plantages du serveur par rapport à TypeScript 6.0.
Nous avons également reçu des retours incroyables de la part d’équipes travaillant à grande échelle :
- Les ingénieurs de Slack nous ont indiqué que TypeScript 7 avait réduit de 40 % le temps d’attente dans leur file d’attente de fusion et ramené le temps de vérification des types en CI d’environ 7,5 minutes à 1,25 minute. Auparavant, le développement local dans l’éditeur était pratiquement « inutilisable » en raison des temps de chargement du serveur de langage, et les ingénieurs laissaient généralement le CI effectuer une vérification complète des types. TypeScript 7 a permis de charger la même base de code en quelques secondes et a rendu la vérification de types locale à nouveau possible.
- Les builds chez Vanta se sont considérablement améliorés, avec une accélération pouvant aller jusqu’à 9 fois plus rapide sur l’un de leurs plus grands projets.
- De même, l’équipe News Services de Microsoft nous a confié que l’adoption de TypeScript 7 leur avait permis d’économiser 400 heures par mois d’attente pour les builds en CI.
- L’année dernière, les ingénieurs travaillant sur PowerBI ont qualifié l’utilisation de TypeScript 7 dans l’éditeur de « salvatrice » pour leur travail sur leur base de code. Ils ont adopté cette expérience par défaut avant même que TypeScript 7 ne prenne en charge la fonctionnalité de renommage dans VS Code.
- Les développeurs travaillant sur le monorepo de Loop étaient également ravis. L’expérience précédente avec l’éditeur était jugée inutilisable à leur échelle, tandis que celle offerte par TypeScript 7 s’est avérée « incroyable ».
- Les développeurs de Canva nous ont indiqué que le service de langage de TypeScript 7 offrait des gains de vitesse spectaculaires, le temps nécessaire pour afficher la première erreur dans leurs éditeurs passant d’environ 58 secondes à environ 4,8 secondes.
Fonctionnement en parallèle avec TypeScript 6.0
Bien que TypeScript 7.0 soit désormais disponible, il n’est pas fourni avec une API. Nous prévoyons que TypeScript 7.1 sera livré avec une nouvelle API (différente), mais d’ici là, nous nous sommes fixé comme priorité de garantir que TypeScript puisse fonctionner en parallèle avec TypeScript 6.0 pour les utilitaires qui ont encore besoin d’un accès programmatique au compilateur (tels que typescript-eslint).
Dans le cadre du processus de transition entre les versions 6.0 et 7.0, nous avons publié un nouveau package de compatibilité, @typescript/typescript6. Ce package fournit un exécutable nommé tsc6, ce qui vous permet, si nécessaire, d’installer TypeScript 7.0 (qui intègre son propre binaire tsc) en parallèle sans conflit de noms. Le nouveau paquet réexporte également l’API TypeScript 6.0, ce qui vous permet d’utiliser tsc pour TypeScript 7, tandis que d’autres outils peuvent continuer à s’appuyer sur la version 6.0.
Étant donné que certains outils, comme typescript-eslint, s’attendent à importer directement depuis TypeScript via des dépendances de pair, nous vous recommandons d’utiliser des alias npm. Vous devriez pouvoir exécuter la commande suivante
Code:
npm install -D typescript@npm:@typescript/typescript6
ou modifier votre fichier package.json comme suit :
Code:
1
2
3
4
5
| {
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.2",
}
} |
Notez que cette opération ne vous laissera qu’un exécutable tsc6. Pour obtenir le tsc de la version 7.0, vous pouvez ajouter un autre alias pour TypeScript 7 et npx tsc fonctionnera alors avec la version 7.0 :
Code:
1
2
3
4
5
6
| {
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
} |
Builds « nightly » et @typescript/native-preview
Jusqu’à présent, la plupart des développeurs ont installé TypeScript 7 via le paquet @typescript/native-preview. Ce paquet proposait des builds « nightly » de la nouvelle base de code et a bien servi la communauté avec plus de 8,5 millions de téléchargements hebdomadaires !
Cependant, à l’avenir, les builds « nightly » reprendront bientôt sous le paquet TypeScript standard avec la balise next. Vous pouvez l’installer avec :
Code:
npm install -D typescript@next
Mise à l’échelle personnalisée : parallélisation et contrôles
TypeScript 7.0 effectue 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 réalisé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. Mais toutes les étapes d’une compilation TypeScript ne sont pas facilement parallélisables.
TypeScript 7 introduit les indicateurs expérimentaux --checkers et --builders pour affiner le comportement de la parallélisation pour des étapes moins triviales telles que la vérification des types et la construction des références de projet. Il introduit également un indicateur --singleThreaded pour désactiver complètement la parallélisation, ce qui peut s’avérer utile pour le débogage ou l’exécution dans des environnements aux ressources limitées.
Parallélisation du vérificateur de types
D’autres é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 types 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’un autre côté, la vérification des types s’appuie parfois sur l’ordre relatif des informations dans un programme ; ainsi, une vérification des types effectuée à partir de zéro doit toujours analyser les mêmes fichiers dans un ordre identique pour garantir des résultats identiques.
Pour permettre la parallélisation tout en évitant ces écueils, TypeScript 7.0 crée un nombre fixe de « workers » de vérification de types, chacun disposant de sa propre vision du monde. Ces « workers » 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 drapeau --checkers. Vous constaterez peut-être qu'augmenter ce nombre peut accélérer encore davantage les compilations sur des bases de code plus volumineuses, où les machines disposent généralement de plus de cœurs de processeur, mais cela se fera généralement au prix d'une consommation de mémoire accrue. Par exemple, dans le tableau ci-dessus, nous avons exécuté TypeScript 7 avec sa valeur par défaut de --checkers 4. Voici à quoi ressemblent les résultats sur la même machine avec --checkers 8.
Comme vous pouvez le constater, ces bases de code bénéficient d’un gain de vitesse plus important lorsque l’on leur consacre davantage de cœurs, mais les résultats varient selon les projets et les machines utilisées.
En revanche, sur des machines disposant de moins de cœurs de processeur et de moins de mémoire (par exemple, les environnements d’exécution CI), vous pouvez réduire ce nombre afin d’éviter toute surcharge inutile ou accidentelle. Vous pouvez spécifier une valeur aussi faible que --checkers 1, ce qui rendra la vérification des types monothread et éliminera les doublons.
Dans de rares cas, modifier le nombre de --checkers peut faire apparaître des résultats dépendants de l’ordre d’exécution. Spécifier un nombre fixe de vérificateurs dans tous les environnements de compilation peut aider à garantir que tout le monde obtient les mêmes résultats, mais cela reste à la discrétion de votre équipe.
Parallélisation des générateurs de références de projet
TypeScript 7.0 peut paralléliser les compilations au sein d’un même projet, mais il est désormais également capable de compiler plusieurs projets simultanément. Ce comportement peut être configuré à l’aide du nouvel indicateur --builders, qui contrôle le nombre de générateurs de références de projet parallèles pouvant s’exécuter simultanément lors d’une compilation avec l’option --build. Cela peut s’avérer particulièrement utile pour les monorepos contenant de nombreux projets.
Tout comme avec l’option --checkers, augmenter le nombre de générateurs peut accélérer les compilations, mais peut se faire au prix d’une consommation de mémoire accrue. Cela a également un effet multiplicateur avec l’option --checkers ; il est donc important de trouver le bon équilibre pour votre machine et votre 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.
Contrairement à --checkers, faire varier le nombre de « builders » ne devrait pas produire de résultats différents ; cependant, la compilation des références de projet est fondamentalement limitée par le graphe de dépendances des projets (à l’exception de la vérification de types sur les bases de code qui exploitent --isolatedDeclarations et génèrent un fichier de déclaration syntaxique séparé).
Mode mono-thread
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 entre TypeScript 6 et 7, lors de l’orchestration externe de compilations parallèles, ou pour l’exécution dans des environnements aux ressources très limitées. Pour activer le mode mono-thread, vous pouvez utiliser le nouvel indicateur --singleThreaded. Cela limitera non seulement le nombre de workers de vérification de types à 1, mais garantira également que l’analyse syntaxique et la génération de fichiers s’effectuent dans un seul thread.
Mode --watch amélioré
TypeScript 7 intègre un mode --watch entièrement repensé. --watch s’appuie désormais sur une nouvelle base inspirée du file-watcher du bundler Parcel, qui offre des capacités de surveillance de fichiers multiplateformes efficaces et stables.
Lorsque notre équipe s’est attelée à porter notre logique de surveillance de fichiers, nous avons rencontré quelques difficultés liées à la surveillance multiplateforme en Go. La bibliothèque standard ne fournit pas d’API intégrée de surveillance des fichiers, et les bibliothèques tierces existantes que nous avons explorées présentaient divers problèmes de stabilité, de performances, de prise en charge multiplateforme ou d’intégration avec les outils de build. Nous avons pu mettre au point des solutions reposant sur des interrogations périodiques pour détecter les modifications de fichiers, ce qui fonctionnait globalement sur tous les systèmes d’exploitation ; cependant, cela s’avérait coûteux en ressources de calcul, en particulier pour les projets à grande échelle comportant de nombreuses dépendances dans node_modules. Même avec des stratégies de planification dynamiques, nous avons constaté que les solutions reposant uniquement sur l’interrogation étaient trop gourmandes en ressources pour une utilisation courante.
Depuis de nombreuses années, Visual Studio Code s’appuie sur @parcel/watcher, et ces dernières années, TypeScript dans VS Code a indirectement tiré parti de ses capacités de surveillance de fichiers. Bien que cela semblait prometteur, l’un des problèmes que nous rencontrions avec le watcher de Parcel est qu’il est écrit en C++ et nécessite donc une chaîne d’outils C++ complète pour sa compilation. Compte tenu de notre expérience positive avec le watcher de Parcel dans VS Code, nous avons exploré la possibilité de le porter en Go à l’aide de quelques shims d’assemblage minimaux afin d’éviter d’introduire une nouvelle dépendance à une chaîne d’outils.
Cette exploration a été couronnée de succès : ce qui avait commencé comme une traduction très directe du C++ vers Go a été affiné pour devenir un code idiomatique en Go qui continue de passer avec succès la suite de tests portée. Le « watcher » est un paquet autonome qui nous a permis de maintenir une séparation claire des préoccupations entre ce que nous souhaitons surveiller et pourquoi. Nous constatons désormais des améliorations significatives en termes de ressources en mode --watch sur toutes les plateformes, et avons reçu des retours positifs de la part des premiers utilisateurs de TypeScript 7.
Nous tenons à remercier Devon Govett, dont le travail sur Parcel a apporté d’immenses avantages tant au projet Visual Studio Code qu’à celui de TypeScript. Nous espérons que ce portage offrira, à terme, de nouvelles opportunités et des perspectives pour le code source original du « watcher » de Parcel.
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 la vérification des types et le comportement en ligne de commande de TypeScript 6.0. Pratiquement tout code TypeScript qui se compile sans erreur avec TypeScript 6.0 (avec le drapeau stableTypeOrdering activé et sans aucun drapeau ignoreDeprecations défini) devrait se compiler de la même manière dans TypeScript 7.0.
Cela dit, TypeScript 7.0 adopte les nouvelles valeurs par défaut de la version 6.0 et génère des erreurs fatales en cas d’utilisation de drapeaux ou de constructions obsolètes dans TypeScript 6.0. Ce point est important, car la version 6.0 est encore relativement récente et de nombreux projets devront s’adapter à ses nouveaux comportements. Nous encourageons les développeurs à adopter TypeScript 6.0 afin de faciliter la transition vers TypeScript 7.0. Vous pouvez également consulter l’article de blog consacré à la sortie de TypeScript 6.0 pour plus de détails sur ces éléments obsolètes.
En bref, les changements notables 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 actuelle d’ECMAScript précédant immédiatement 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 source internes doivent être explicitement définis.
- types est désormais défini par défaut sur [], et l’ancien comportement peut être rétabli en le définissant sur ["*"].
Nous pensons que les modifications apportées à rootDir et à types sont peut-être les plus « surprenantes », mais elles peuvent être facilement atténuées. Les projets dans lesquels le fichier tsconfig.json se trouve en dehors d’un répertoire tel que src devront simplement inclure rootDir pour conserver la même structure de répertoires.
Code:
1
2
3
4
5
6
7
| {
"compilerOptions": {
// ...
+ "rootDir": "./src"
},
"include": ["./src"]
} |
En ce qui concerne la modification de types, les projets qui dépendent de déclarations globales spécifiques devront les énumérer explicitement. Par exemple,
Code:
1
2
3
4
5
6
| {
"compilerOptions": {
// Explicitly list the @types packages you need (e.g. bun, mocha, jasmine, etc.)
+ "types": ["node", "jest"]
}
} |
Les fonctionnalités obsolètes qui sont désormais considérées comme des erreurs graves sans conséquence sont les suivantes :
- target : es5 n’est plus pris en charge.
- downlevelIteration n’est plus pris en charge.
- moduleResolution : node/node10 ne sont plus pris en charge ; nodenext et bundler sont recommandés à la place.
- module : amd, umd, systemjs, none ne sont plus pris en charge ; esnext ou preserve sont recommandés en association avec des bundlers ou une résolution de modules basée sur le navigateur.
- baseUrl n’est plus pris en charge, et les chemins d’accès peuvent être mis à jour pour être relatifs à la racine du projet plutôt qu’à baseUrl.
- moduleResolution : classic n’est plus pris en charge ; bundler ou nodenext sont les remplacements recommandés.
- esModuleInterop et allowSyntheticDefaultImports ne peuvent pas ê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 à la place le mot-clé with (afin de s’aligner sur les évolutions de la syntaxe de l’attribut import d’ECMAScript).
- Les directives /// <reference no-default-lib /> ne sont plus respectées lorsque skipDefaultLibCheck est activé.
- Les compilations en ligne de commande ne peuvent pas accepter de chemins d’accès aux fichiers lorsque le répertoire courant contient un fichier tsconfig.json, sauf si le drapeau explicite --ignoreConfig est passé.
Les types de littéraux de modèle préservent désormais les points de code Unicode
TypeScript 7.0 traite désormais les points de code Unicode de manière plus naturelle lors de l’inférence à partir des types de littéraux de modèle. Par exemple :
Code:
1
2
3
4
5
6
| type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"abc">;
// ^
// In 7.0: ["", "abc"]
// Previously: ["\ud83d", "\ude00abc"] |
Auparavant, TypeScript suivait ici le comportement d’indexation UTF-16 de JavaScript et divisait "😀" en deux moitiés d’une paire de substituts (\ud83d et \ude00). Cela était techniquement cohérent avec l’indexation en JavaScript (par exemple, le type Head déduit était égal à "😀abc"[0]), mais ce n’était généralement pas ce que les utilisateurs souhaitaient, et cela pouvait produire des types de littéraux de chaîne contenant des substituts non appariés qui n’ont pas de sens sémantique.
Il s’agit d’un changement rompant pour la manipulation de chaînes au niveau des types qui modélisait intentionnellement les unités de code UTF-16, comme certaines utilitaires de longueur de chaîne. En pratique, nous nous attendons à ce que ce nouveau comportement soit plus utile et moins surprenant : l’inférence des littéraux de modèle suit désormais la même intuition que l’itération d’une chaîne avec for...of ou son étalement avec [...str], où "😀" est traité comme une seule unité.
Différences par rapport à JavaScript
Lors du portage de la base de code existante, nous en avons également profité pour revoir le fonctionnement de notre 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 pour l’analyse et l’inférence de types. La plupart du temps, cela reposait sur des modèles de codage courants, mais il arrivait parfois que cela repose 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 peu rigoureuse, elle nécessitait un certain nombre de compromis et de cas particuliers pour bien fonctionner, et s’écartait à plusieurs égards de l’analyse effectuée par TypeScript dans les fichiers .ts.
Dans TypeScript 7.0, nous avons remanié notre prise en charge de JavaScript afin de la rendre plus cohérente avec la manière dont nous analysons les fichiers TypeScript. Voici quelques-unes des différences :
- Les valeurs ne peuvent plus être utilisées là où des types sont attendus ; écrivez plutôt typeof someValue.
- @enum n'est plus reconnu spécifiquement ; créez un @typedef sur (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration].
- Un ? isolé ne peut plus être utilisé comme type – utilisez any à la place.
- @class ne transforme pas une fonction en constructeur – utilisez plutôt une déclaration de classe.
- Le ! en postfixe n’est pas pris en charge – utilisez simplement T.
- Les noms de types doivent être définis à l’intérieur d’une balise @typedef (par exemple /** @typedef {T} TypeAliasName */), et non à côté d’un identifiant (par exemple /** @typedef {T} */ TypeAliasName;).
- La syntaxe des fonctions de type closure (par exemple function(string): void) n’est plus prise en charge – utilisez plutôt les raccourcis TypeScript (par exemple (s: string) => void).
De plus, certains modèles JavaScript, tels que 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.
Bien que certains aspects de notre prise en charge de JS soient en pleine évolution, nous avons mis à jour ce fichier CHANGES.md afin de détailler plus précisément les différences entre TypeScript 6.0 et 7.0.
Expérience dans l’éditeur
Comme nous l’avons mentionné plus haut, les améliorations de 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. Pour les utilisateurs de VS Code, nous proposons une extension dédiée à TypeScript 7. Une fois cette extension installée, elle deviendra automatiquement l’expérience par défaut. Vous pouvez la désactiver et la réactiver à tout moment à l’aide des commandes « Désactiver le serveur de langage TypeScript 7 » et « Activer le serveur de langage TypeScript 7 » de la palette de commandes. Dans les semaines à venir, la prise en charge de TypeScript 7 sera intégrée directement à VS Code.
Pour les utilisateurs de Visual Studio, la dernière version de l’IDE activera automatiquement TypeScript 7 en fonction de votre espace de travail. Vous n’aurez rien à faire de particulier.
Bien sûr, TypeScript 7 devrait fonctionner parfaitement dans n’importe quel éditeur de votre choix. La nouvelle infrastructure repose sur le protocole LSP (Language Server Protocol) et est capable d’exploiter plusieurs threads pour traiter les requêtes simultanées aussi rapidement que possible.
Depuis son lancement, nous avons ajouté des fonctionnalités qui manquaient, telles que les importations automatiques, les survols extensibles, les astuces intégrées, les « code lenses », la fonction « aller à la définition source », l’édition liée à JSX et la complétion des balises, entre autres. Les fonctionnalités manquantes de la version bêta de TypeScript 7.0, telles que la mise en évidence sémantique, le « tri des importations », la « suppression des importations inutilisées », et bien d’autres encore, sont désormais disponibles.
De plus, nous avons continué à améliorer les performances et la stabilité au cours des derniers mois. Nous avons refondu une grande partie de notre infrastructure de tests et de diagnostics afin de garantir un niveau de qualité élevé, ce qui nous permet de soumettre le serveur de langage à des tests de fuzz sur les principales bases de code TypeScript et JavaScript disponibles sur GitHub. Comme nous l’avons mentionné plus haut, le nouveau serveur de langage de TypeScript 7 est nettement plus stable que celui de TypeScript 6.
TypeScript et les langages intégrés
Il convient de souligner que les workflows utilisant Vue, MDX, Astro, Svelte et d’autres frameworks ne pourront probablement pas encore tirer parti de TypeScript 7. De même, la vérification de types spécialisée au sein de modèles tels que ceux d’Angular n’utilisera probablement pas non plus TypeScript 7. Cela s’explique principalement par le fait que TypeScript 7 ne propose pas encore d’API programmatique stable ; par conséquent, les outils (tels que Volar) qui intègrent TypeScript dans leurs propres compilateurs et services linguistiques ne peuvent actuellement s’appuyer que sur TypeScript 6.0. Nous pensons qu’il s’agit d’un problème temporaire, car nous nous engageons à apporter une solution à ce sujet. Nous travaillerons activement avec les responsables de ces projets pour garantir que TypeScript 7 prenne en charge ces workflows.
D’ici là, nous recommandons aux équipes d’utiliser TypeScript 7 dans les cas où les plugins de serveur de langage ne sont pas nécessaires. Les projets utilisant Angular peuvent combiner TypeScript 7 pour bénéficier d’une détection rapide des erreurs à l’échelle du projet via la CLI avec tsc, et TypeScript 6.0 pour la prise en charge par l’éditeur. Les projets utilisant Vue, MDX, Astro, Svelte et autres devront continuer à utiliser TypeScript 6.0 pour le moment. Dans VS Code, les utilisateurs peuvent simplement exécuter la commande « Disable TypeScript 7 Language Server » pour revenir à TypeScript 6.0.
La voie à suivre
TypeScript 7.0 marque une étape majeure dans le projet TypeScript. Ce portage a été la priorité de notre équipe pendant plus d’un an, et maintenant que la version 7.0 est disponible, nous allons nous recentrer sur le développement de nouvelles fonctionnalités, des améliorations ergonomiques, des gains de performances supplémentaires et la mise en œuvre d’une nouvelle API pour l’écosystème au sens large. Bien que cela puisse sembler important, nous prévoyons un calendrier assez similaire à celui des versions antérieures à TypeScript 7.0, avec la publication de nouvelles versions riches en fonctionnalités tous les 3 à 4 mois. Avec TypeScript 7.1 qui se profile à l’horizon, nous espérons combler les éventuelles lacunes afin de faire progresser la communauté.
Source : Annonce TypeScript 7.0
Et vous ?
:fleche: Pensez-vous que cette annonce est crédible ou pertinente ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: Microsoft annonce la version bêta de TypeScript 7.0, basée sur le langage Go, avec des performances « environ 10 fois plus rapides » que la version 6.0, des capacités de traitement parallèle et plus encore
:fleche: TypeScript se tourne vers Gopher : Microsoft mise sur Go pour multiplier la vitesse par 10, par Kush Creates
:fleche: 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
