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