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...
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.