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
Microsoft annonce la version candidate (RC) de TypeScript 5.9. TypeScript 5.9 RC apporte des mise à jour à tsc --init, la prise en charge de import defer et de --module node20, ainsi que des descriptions récapitulatives dans les API DOM. Par rapport à la version bêta, cette version apporte quelques corrections, notamment la restauration de AbortSignal.abort() dans la bibliothèque DOM.
TypeScript est un langage qui s'appuie sur JavaScript en ajoutant une syntaxe pour les types. L'écriture de types dans le code permet d'expliquer l'intention et de faire vérifier le code par d'autres outils pour détecter les erreurs comme les fautes de frappe, les problèmes avec nullet undefined, et plus encore. Les types alimentent également les outils d'édition de TypeScript, comme l'auto-complétion, la navigation dans le code et les refactorisations que vous pouvez voir dans des éditeurs tels que Visual Studio et VS Code. En fait, TypeScript et son écosystème alimentent l'expérience JavaScript dans ces deux éditeurs également.
Voici les nouveautés de TypeScript 5.9 :
tsc --init minimal et mis à jour
Depuis un certain temps, le compilateur TypeScript prend en charge un indicateur --init qui permet de créer un fichier tsconfig.json dans le répertoire actuel. Au cours des dernières années, l'exécution de tsc --init créait un fichier tsconfig.json très « complet », rempli de paramètres commentés et de leurs descriptions.
Cependant, il était courant de supprimer immédiatement la plupart du contenu de ces nouveaux fichiers tsconfig.json. Lorsque les utilisateurs souhaitent découvrir de nouvelles options, ils s'appuient sur la fonction d'auto-complétion de leur éditeur ou qu'ils naviguent vers la référence tsconfig. La fonction de chaque paramètre est également documentée sur cette même page et peut être consultée via les infobulles/outils d'aide/informations rapides de l'éditeur. Bien que l'affichage de certains paramètres commentés puisse être utile, le fichier tsconfig.json généré était souvent considéré comme excessif.
Avec cette version, tsc --init s'initialise avec quelques paramètres plus prescriptifs. Parmi les points faibles courants et les désagréments rencontrés par les utilisateurs lorsqu'ils créent un nouveau projet TypeScript, on peut citer que la plupart des utilisateurs écrivent dans des modules (et non dans des scripts globaux), et --moduleDetection peut forcer TypeScript à traiter chaque fichier d'implémentation comme un module. Les développeurs souhaitent également souvent utiliser les dernières fonctionnalités ECMAScript directement dans leur runtime, de sorte que --target peut généralement être défini sur esnext. Les utilisateurs de JSX trouvent souvent que revenir à --jsx est une friction inutile, et ses options sont légèrement déroutantes. Et souvent, les projets finissent par charger plus de fichiers de déclaration depuis TypeScript n'en a réellement besoin, mais spécifier un tableau de types vide peut aider à limiter cela.
Dans TypeScript 5.9, un simple tsc --init sans autre indicateur générera le fichier tsconfig.json suivant :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Prise en charge de import defer
TypeScript 5.9 introduit la prise en charge de la proposition d'évaluation différée des modules ECMAScript à l'aide de la nouvelle syntaxe import defer. Cette fonctionnalité vous permet d'importer un module sans exécuter immédiatement le module et ses dépendances, ce qui vous offre un meilleur contrôle sur le moment où le travail et les effets secondaires se produisent.
La syntaxe n'autorise que les importations d'espaces de noms :
Code:import defer * as feature from "./some-feature.js";
Le principal avantage de import defer est que le module n'est évalué que lors de sa première utilisation. Prenons l'exemple suivant :
Code:
2
3
4
5
6
7
8
9
10
11
Lorsque vous utilisez import defer, la fonction initializationWithSideEffects() ne sera pas appelée tant que vous n'aurez pas accédé à une propriété de l'espace de noms importé :
Code:
2
3
4
5
6
7
8
9
Comme l'évaluation du module est différée jusqu'à ce que vous accédiez à un membre du module, vous ne pouvez pas utiliser d'importations nommées ou d'importations par défaut avec import defer :
Code:
2
3
4
5
6
7
8
Notez que lorsque vous écrivez import defer, le module et ses dépendances sont entièrement chargés et prêts à être exécutés. Cela signifie que le module doit exister et sera chargé à partir du système de fichiers ou d'une ressource réseau. La principale différence entre import normale et import difer réside dans le fait que l'exécution des instructions et des déclarations est différée jusqu'à ce que vous accédiez à une propriété de l'espace de noms importé.
Cette fonctionnalité est particulièrement utile pour charger de manière conditionnelle des modules dont l'initialisation est coûteuse ou spécifique à une plateforme. Elle peut également améliorer les performances de démarrage en différant l'évaluation des modules pour les fonctionnalités de l'application jusqu'à ce qu'elles soient réellement nécessaires.
Notez que import defer n'est pas transformé ou « déclassé » par TypeScript. Il est destiné à être utilisé dans des environnements d'exécution qui prennent en charge cette fonctionnalité de manière native, ou par des outils tels que des bundlers qui peuvent appliquer la transformation appropriée. Cela signifie que import defer ne fonctionnera que sous les modes --module preserve et esnext.
Prise en charge de --module node20
TypeScript fournit plusieurs options node* pour les paramètres --module et --moduleResolution. Plus récemment, --module nodenext a pris en charge la possibilité de requérir () des modules ECMAScript à partir de modules CommonJS, et rejette correctement les assertions d'importation (au profit des attributs d'importation liés aux normes).
TypeScript 5.9 apporte une option stable pour ces paramètres appelée node20, destinée à modéliser le comportement de Node.js v20. Contrairement à --module nodenext ou --moduleResolution nodenext, cette option ne devrait pas connaître de nouveaux comportements à l'avenir. Contrairement à nodenext, la spécification de --module node20 implique --target es2023, sauf configuration contraire. --module nodenext, en revanche, implique le --target esnext flottant.
Descriptions sommaires dans les API DOM
Auparavant, la plupart des API DOM dans TypeScript renvoyaient uniquement vers la documentation MDN de l'API. Ces liens étaient utiles, mais ils ne fournissaient pas de résumé rapide du fonctionnement de l'API. Grâce à quelques modifications, TypeScript inclut désormais des descriptions sommaires pour de nombreuses API DOM basées sur la documentation MDN.
Info-bulles extensibles (aperçu)
Les infobulles (également appelées « info-bulles de l'éditeur » et « info-bulles ») peuvent être très utiles pour consulter les variables afin de connaître leur type, ou les alias de type afin de savoir à quoi ils font référence. Cependant, il est courant que les utilisateurs souhaitent approfondir leurs connaissances et obtenir des détails sur ce qui est affiché dans l'info-bulle. Par exemple, si nous passons la souris sur le paramètre options dans l'exemple suivant :
Code:export function drawButton(options: Options): void
Nous obtenons (parameter) options: Options.
Pour vous aider, TypeScript 5.9 propose désormais en avant-première une fonctionnalité appelée « expandable hovers » (survols extensibles) ou « quick info verbosity » (verbosité des informations rapides). Si vous utilisez un éditeur tel que VS Code, vous verrez désormais un bouton + et - à gauche de ces infobulles. Cliquer sur le bouton + permettra d'afficher les types de manière plus détaillée, tandis que cliquer sur le bouton - vous ramènera à la vue précédente.
Longueur maximale configurable des infobulles
Il arrive parfois que les info-bulles soient si longues que TypeScript les tronque pour les rendre plus lisibles. L'inconvénient est que les informations les plus importantes sont souvent omises de l'info-bulle, ce qui peut être frustrant. Pour remédier à cela, le serveur de langage de TypeScript 5.9 prend en charge une durée d'affichage configurable, qui peut être définie dans VS Code via le paramètre js/ts.hover.maximumLength.
De plus, la nouvelle longueur par défaut est nettement supérieure à la précédente. Cela signifie que dans TypeScript 5.9, vous devriez voir plus d'informations dans vos info-bulles par défaut.
Optimisations
Instantiations de cache sur les mappeurs
Lorsque TypeScript remplace les paramètres de type par des arguments de type spécifiques, il peut finir par instancier à plusieurs reprises de nombreux types intermédiaires identiques. Dans des bibliothèques complexes telles que Zod et tRPC, cela peut entraîner à la fois des problèmes de performances et des erreurs liées à une profondeur d'instanciation de type excessive. Grâce à une modification apportée par Mateusz Burzyński, TypeScript 5.9 est capable de mettre en cache de nombreuses instanciations intermédiaires lorsque le travail a déjà commencé sur une instanciation de type spécifique. Cela permet d'éviter beaucoup de travail et d'allocations inutiles.
Éviter la création de fermetures dans fileOrDirectoryExistsUsingSource
En JavaScript, une expression de fonction alloue généralement un nouvel objet de fonction, même si la fonction wrapper se contente de transmettre des arguments à une autre fonction sans capturer de variables. Dans les chemins de code autour des vérifications d'existence de fichiers, l'équipe de Microsoft a trouvé des exemples de ces appels de fonction de transmission, même si les fonctions sous-jacentes ne prenaient qu'un seul argument. Compte tenu du nombre de vérifications d'existence pouvant avoir lieu dans des projets plus importants, ils ont cité une accélération d'environ 11 %.
Changements comportementaux notables
Modifications de lib.d.ts
Les types générés pour le DOM peuvent avoir un impact sur la vérification des types de votre base de code.
De plus, un changement notable est que ArrayBuffer a été modifié de telle sorte qu'il n'est plus un supertype de plusieurs types TypedArray différents. Cela inclut également les sous-types de UInt8Array, tels que Buffer de Node.js. En conséquence, vous verrez apparaître de nouveaux messages d'erreur tels que :
Code:
2
3
4
5
Si vous rencontrez des problèmes avec Buffer, vous pouvez d'abord vérifier que vous utilisez la dernière version du package @types/node. Cela peut impliquer d'exécuter
Code:npm update @types/node --save-dev
La plupart du temps, la solution consiste à spécifier un type de tampon sous-jacent plus précis au lieu d'utiliser le type ArrayBufferLike par défaut (c'est-à-dire en écrivant explicitement Uint8Array<ArrayBuffer> plutôt que simplement Uint8Array).
Modifications de l'inférence des arguments de type
Afin de corriger les « fuites » de variables de type lors de l'inférence, TypeScript 5.9 pourrait introduire des modifications dans les types et éventuellement de nouvelles erreurs dans certaines bases de code. Celles-ci sont difficiles à prévoir, mais peuvent souvent être corrigées en ajoutant des arguments de type aux appels de fonctions génériques.
La suite ?
Récemment, Microsoft s'est concentré sur le portage natif de TypeScript, qui sera finalement disponible sous le nom de TypeScript 7. Pour rappel, en mars, 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.
Selon Anders Hejlsberg, architecte principal de Microsoft pour TypeScript, "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". Avec la sortie de TypeScript 5.9 RC, Microsoft annonce que vous pouvez déjà essayer le portage natif en consultant les aperçus natifs de TypeScript, qui sont publiés.
Étant donné que peu de choses ont changé depuis la version bêta de TypeScript 5.9, Microsoft prévoit de publier TypeScript 5.9 en tant que version candidate finale pour début août.
Source : Annonce de Microsoft
Et vous ?
:fleche: Pensez-vous que ces améliorationts sont crédibles ou pertinentes ?
:fleche: Quel est votre avis sur cette version ?
Voir aussi :
:fleche: Microsoft annonce la disponibilité de TypeScript 5.8, apportant des vérifications plus granulaires pour les branches dans les expressions de retour, ainsi que plusieurs autres améliorations
:fleche: À partir de la version 23.6.0, Node.js prend en charge TypeScript par défaut, en raison de sa popularité croissante. TypeScript étant la fonctionnalité la plus demandée sur Node.js
:fleche: WebStorm 2025.1 est disponible avec une meilleure prise en charge d'Angular et des monorepos et bien d'autres nouveautés et améliorations
