Microsoft publie TypeScript 4.2 avec la prise en charge de Abstract Constructor Types

Et des contrôles plus stricts pour l'opérateur in

Microsoft publie TypeScript 4.2 avec la prise en charge de Abstract Constructor Types
et des contrôles plus stricts pour l'opérateur in

Microsoft a annoncé mardi la disponibilité générale de TypeScript 4.2, avec de nouvelles fonctionnalités et quelques autres changements. Pour ceux qui ne sont pas familiers avec TypeScript, il s'agit d'une extension de JavaScript qui ajoute des types statiques et la vérification de type. Avec les types, vous pouvez indiquer exactement ce que prennent vos fonctions et ce qu'elles vont renvoyer. Vous pouvez ensuite utiliser le vérificateur de type TypeScript pour détecter de nombreuses erreurs courantes comme les fautes de frappe, l'oubli de traiter les caractères nuls et indéfinis, etc.

Comme le code TypeScript ressemble à du JavaScript avec des types, tout ce que vous savez sur le JavaScript s'applique toujours. Lorsque vous en avez besoin, vos types peuvent être supprimés, ce qui vous laisse un JavaScript propre, lisible et exécutable partout. Voici ci-dessous un aperçu des nouvelles fonctionnalités et des modifications intervenues dans cette version.


Préservation des alias de type plus intelligent

TypeScript permet de déclarer de nouveaux noms pour des types appelés alias de type. Si vous écrivez un ensemble de fonctions qui fonctionnent toutes sur string | number | boolean, vous pouvez écrire un alias de type pour éviter de vous répéter sans cesse. Mais parfois, TypeScript ne résout tout simplement pas les types correctement. Il peut renvoyer les bons types, mais ne pas renvoyer le bon alias. L'alias peut être important et ne doit pas être perdu en cours de route. Selon Daniel Rosenwasser, gestionnaire de programme au sein de l'équipe TypeScript chez Microsoft, dans TypeScript 4.2, les procédures sont un peu plus intelligentes.

TypeScript 4.2 garde une trace de la façon dont les types ont été construits en conservant des parties de leur écriture originale et de leur construction au fil du temps. Il garde également une trace des alias de type et les différencie des instances d'autres alias. Le fait de pouvoir imprimer les types en fonction de la façon dont vous les avez utilisés dans votre code signifie que, en tant qu'utilisateur de TypeScript, vous pouvez éviter l'affichage de certains types énormes, ce qui se traduit souvent par une meilleure sortie des fichiers .d.ts, des messages d'erreur et un affichage des types dans l'éditeur sous forme d'infobulles et d'aide à la signature.

Les éléments dans les types de n-uplets

Dans TypeScript, les n-uplets (tuples) sont destinés à modéliser des tableaux avec des longueurs et des types d'éléments spécifiques. D'après, Rosenwasser, au fil du temps, les n-uplets de TypeScript sont devenus de plus en plus sophistiqués, car ils sont également utilisés pour modéliser des choses comme les listes de paramètres en JavaScript. Par conséquent, ils peuvent comporter des éléments optionnels et des éléments de repos, et peuvent même comporter des étiquettes pour l'outillage et la lisibilité. Dans TypeScript 4.2, les autres éléments ont été spécifiquement développés dans la manière dont ils peuvent être utilisés.

Dans les versions précédentes, TypeScript n'autorisait que les éléments de repos à la toute dernière position d'un type de n-uplet. Cependant, désormais, les éléments de repos peuvent se trouver n'importe où dans un n-uplet, avec seulement une restriction. Rosenwasser a expliqué que la seule restriction est qu'un élément de repos peut être placé n'importe où dans un n-uplet, tant qu'il n'est pas suivi d'un autre élément optionnel ou d'un élément de repos. En d'autres termes, un seul élément de repos par n-uplet, et aucun élément optionnel après les éléments de repos.

Ces éléments de repos non traînants peuvent être utilisés pour modéliser des fonctions qui prennent un nombre quelconque d'arguments principaux, suivis de quelques arguments fixes. « Même si JavaScript n'a pas de syntaxe pour modéliser les paramètres de repos principaux, nous avons pu déclarer doStuff comme une fonction qui prend des arguments principaux en déclarant le paramètre de repos "args" avec un type de n-uplet qui utilise un élément de repos principal. Cela peut aider à modéliser de nombreux JavaScript existants », a-t-il déclaré.

Des contrôles plus stricts pour l'opérateur in

Selon l'équipe, l'opérateur "in" est pratique pour savoir si une méthode ou une propriété se trouve dans un objet. Cependant, en JavaScript, l'utilisation d'un type non objet sur le côté droit de l'opérateur "'in" est une erreur d'exécution. Autrement dit, il échouera à l'exécution s'il est vérifié par rapport à une primitive. TypeScript 4.2 garantit que cela peut être détecté au moment de la compilation. Cette vérification est assez conservatrice pour la plupart, donc si vous avez reçu une erreur à ce sujet, il s'agit probablement d'un problème dans le code.

En fait, vous obtiendrez une erreur vous indiquant explicitement ce qui se passe. Comme cet opérateur a été rendu plus strict, cette version pourrait introduire des modifications de rupture.

• --noPropertyAccessFromIndexSignature

Il s'agit ici d'une autre configuration du compilateur intervenue dans TypeScript 4.2. En TypeScript, vous pouvez accéder aux propriétés en utilisant la syntaxe des éléments entre crochets ou la syntaxe des points comme JavaScript. Cet accesseur est possible lorsque la clé est une chaîne de caractères. Cependant, selon l'équipe, cela s'avère compliqué dans les situations où vous devez travailler avec des objets qui ont des propriétés arbitraires. Par exemple, imaginez une API dans laquelle il est courant de mal orthographier le nom d'une propriété en ajoutant un caractère "s" supplémentaire à la fin.

Dans le but de faciliter ce genre de situations, il y a quelque temps, TypeScript a rendu possible l'utilisation d'une syntaxe d'accès aux propriétés "pointillées" comme "person.name" lorsqu'un type avait une signature d'index de chaîne de caractères. Cela a également facilité la transition du code JavaScript existant vers TypeScript. Cependant, l'assouplissement de la restriction a également permis de faciliter l'orthographe d'une propriété explicitement déclarée. Dans certains cas, les utilisateurs préfèrent obtenir un message d'erreur lorsqu'un accès à une propriété pointillée ne correspond pas à une déclaration de propriété spécifique.

C'est pourquoi TypeScript 4.2 introduit un nouveau drapeau appelé "--noPropertyAccessFromIndexSignature". Dans ce mode, vous serez invité à adopter l'ancien comportement de TypeScript qui génère une erreur. Ce nouveau paramètre ne fait pas partie de la famille des drapeaux stricts, car l'équipe pense que les utilisateurs le trouveront plus utile sur certaines bases de code que sur d'autres.

Abstract Constructor Types

TypeScript permet de marquer une classe comme abstraite. Cela indique à TypeScript que la classe est uniquement destinée à être étendue, et que certains membres doivent être complétés par une sous-classe pour créer une instance. Pour garantir l'application cohérente de cette restriction dans les nouvelles classes abstraites, vous ne pouvez pas attribuer une classe abstraite à un objet qui attend une signature de construction. Selon l'équipe, cela est une bonne chose si vous voulez exécuter du code comme un nouveau Ctor, mais c'est trop restrictif si vous voulez écrire une sous-classe de Ctor.

Cela ne fonctionne pas non plus très bien avec les types d'aide intégrés comme InstanceType. C'est pourquoi TypeScript 4.2 vous permet de spécifier un modificateur abstrait sur les signatures des constructeurs. L'ajout du modificateur abstrait à une signature de constructeur signale que vous pouvez passer dans les constructeurs abstraits. Cela ne vous empêche pas de passer dans d'autres classes/fonctions de constructeur qui sont "concrètes", cela signale simplement qu'il n'y a pas d'intention d'exécuter le constructeur directement, donc il est sûr de passer dans l'un ou l'autre type de classe.

Comprendre la structure de votre projet avec --explainFiles

Rosenwasser a écrit qu'un scénario étonnamment courant pour les utilisateurs de TypeScript est de se demander "pourquoi TypeScript inclut-il ce fichier ? Inférer les fichiers de votre programme s'avère être un processus compliqué, et il y a donc de nombreuses raisons pour lesquelles une combinaison spécifique de lib.d.ts a été utilisée, pourquoi certains fichiers dans node_modules sont inclus, et pourquoi certains fichiers sont inclus même si vous pensiez que le fait de spécifier "exclude" les exclurait. C'est pourquoi TypeScript 4.2 fournit maintenant un drapeau "--explainFiles".

Lorsque vous utilisez cette option, le compilateur TypeScript fournit des informations très détaillées sur les raisons pour lesquelles un fichier a été inclus dans votre programme. Pour le lire plus facilement, vous pouvez transférer la sortie vers un fichier, ou la transmettre à un programme qui peut facilement la visualiser. En général, le résultat commence par une liste des raisons pour lesquelles les fichiers lib.d.ts ont été...