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é inclus, puis les fichiers locaux, et enfin les fichiers node_modules. Pour l'instant, l'équipe ne donne aucune garantie quant au format de sortie, il pourrait changer avec le temps.
Changements de rupture
TypeScript 4.2 contient quelques modifications de rupture, mais l'équipe pense qu'elles devraient être gérables lors d'une mise à jour.
Mises à jour de lib.d.ts
Comme pour chaque version de TypeScript, les déclarations pour lib.d.ts (en particulier les déclarations générées pour les contextes Web), ont changé. Il y a plusieurs changements, bien que ceux d'Intl et de ResizeObserver puissent être les plus perturbateurs.
Les erreurs noImplicitAny s'appliquent aux expressions de rendement libre
Lorsque la valeur d'une expression de rendement est saisie, mais que TypeScript n'est pas en mesure de déterminer immédiatement le type que vous souhaitez lui faire parvenir (c'est-à-dire que l'expression de rendement n'est pas tapée contextuellement), TypeScript émet alors une erreur implicite.
Contrôles de fonctionnement étendus non sollicités
À partir de TypeScript, les contrôles de fonction non appelés fonctionneront désormais de manière cohérente dans les expressions && et || lors de l'utilisation de "--strictNullChecks". Selon l'équipe, cela peut être une source de nouvelles ruptures, mais c'est généralement une indication d'une erreur logique dans le code existant.
Les arguments de type en JavaScript ne sont pas analysés comme des arguments de type
Les arguments de type n'étaient déjà pas autorisés en JavaScript, mais dans TypeScript 4.2, l'analyseur les analysera d'une manière plus conforme aux spécifications. L'équipe a déclaré que cela peut avoir un impact sur vous si vous utilisez l'API de TypeScript pour analyser les constructions de types dans les fichiers JavaScript, ce qui peut se produire lorsque vous essayez d'analyser des fichiers Flow.
L'opérateur in n'autorise plus les types primitifs sur le côté droit
Comme il est mentionné ci-dessus, c'est une erreur d'utiliser une primitive sur le côté droit de l'opérateur "in", et TypeScript 4.2 est plus strict sur ce type de code.
Limites de taille des n-uplets pour les écarts
D'après Rosenwasser, les n-uplets peuvent être réalisés en utilisant n'importe quelle sorte de syntaxe de diffusion (...) en TypeScript. Parfois, ces n-uplets peuvent accidentellement devenir énormes, ce qui peut rendre la vérification de la typographie très longue. Au lieu de laisser le processus de vérification de type en suspens (ce qui est particulièrement mauvais dans les scénarios d'éditeurs), TypeScript a mis en place un limiteur pour éviter de faire tout ce travail.
Source : Microsoft
Et vous ?
Que pensez-vous des nouvelles fonctionnalités de TypeScript 4.2 ?Voir aussi
TypeScript 4.0 Beta permet aux tuples d'accepter un nombre variable de paramètres et apporte l'inférence de propriété de classe des constructeurs The State of the Octoverse 2020 : Python et TypeScript gagnent en popularité parmi les langages de programmation, alors que JavaScript continue d'être le langage le plus populaire sur GitHub State of JavaScript 2020 : TypeScript leader incontestable des déclinaisons de JavaScript, le typage statique devient la fonctionnalité la plus demandée et React reste le framework front-end dominant Quels sont les frameworks JavaScript que vous aimeriez apprendre en 2020 ? Voici quelques propositions qui sont tributaires des cas d'utilisations