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 null et 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 : | Sélectionner tout |
1 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 | {
// Visit https://aka.ms/tsconfig to read more about this file
"compilerOptions": {
// File Layout
// "rootDir": "./src",
// "outDir": "./dist",
// Environment Settings
// See also https://aka.ms/tsconfig_modules
"module": "nodenext",
"target": "esnext",
"types": [],
// For nodejs:
// "lib": ["esnext"],
// "types": ["node"],
// and npm install -D @types/node
// Other Outputs
"sourceMap": true,
"declaration": true,
"declarationMap": true,
// Stricter Typechecking Options
"noUncheckedIndexedAccess": true,
"exactOptionalPropertyTypes": true,
// Style Options
// "noImplicitReturns": true,
// "noImplicitOverride": true,
// "noUnusedLocals": true,
// "noUnusedParameters": true,
// "noFallthroughCasesInSwitch": true,
// "noPropertyAccessFromIndexSignature": true,
// Recommended Options
"strict": true,
"jsx": "react-jsx",
"verbatimModuleSyntax": true,
"isolatedModules": true,
"noUncheckedSideEffectImports": true,
"moduleDetection": "force",
"skipLibCheck": true,
}
} |
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 : | Sélectionner tout |
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 : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | // ./some-feature.ts
initializationWithSideEffects();
function initializationWithSideEffects() {
// ...
specialConstant = 42;
console.log("Side effects have occurred!");
}
export let specialConstant: number; |
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 : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | import defer * as feature from "./some-feature.js"; // No side effects have occurred yet // ... // As soon as `specialConstant` is accessed, the contents of the `feature` // module are run and side effects have taken place. console.log(feature.specialConstant); // 42 |
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 : | Sélectionner tout |
1 2 3 4 5 6 7 8 | // Not allowed
import defer { doSomething } from "some-module";
// Not allowed
import defer defaultExport from "some-module";
// Only this syntax is supported
import defer * as feature from "some-module"; |
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 : | Sélectionner tout |
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,...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.