Que signifie la proposition de syntaxe de type ES de Microsoft pour JavaScript
JavaScript pourrait bientôt avoir sa propre syntaxe de type si une proposition soumise par Microsoft et d’autres développeurs plus tôt cette année devient une partie de la norme ECMAScript. L’initiative prévoit d’ajouter la prise en charge des « types en tant que commentaires » au langage JavaScript, permettant aux développeurs d’annoter le code avec des informations de type qui seront utilisées par d’autres composants de l’écosystème.
Sommaire
La syntaxe
La syntaxe proposée ressemble à ceci :
function sayAge(name: string, age: number) { console.log(`${name} is ${age} years old.`); } sayAge("JavaScript", 26);
Il sera familier à tous ceux qui ont déjà utilisé TypeScript, le sur-ensemble typé de JavaScript de Microsoft. TypeScript a été largement adopté dans l’industrie ; cette nouvelle proposition prétend apporter certains de ses avantages au monde JavaScript au sens large.
Qu’est-ce que la proposition n’est pas ?
Si elle est approuvée, cette proposition vous permettra d’écrire du JavaScript parfaitement valide avec les annotations de type indiquées ci-dessus. Il sera accepté par les runtimes JavaScript tels que les navigateurs Web, Node.js et Deno qui respectent la norme ES.
La proposition n’étend cependant pas le langage JavaScript. Vos annotations de type seront exactement cela : des métadonnées inertes qui n’ont aucun effet sur le compilateur JavaScript ou l’exécution de votre code. Un appel de fonction tel que celui-ci fonctionnerait à l’exécution :
function sayAge(name: string, age: number) { console.log(`${name} is ${age} years old.`); } // "age" is a string when it should be a number, but this is still allowed sayAge("JavaScript", "twenty");
L’idée est de proposer une nouvelle syntaxe de type officiellement supportée mais complètement ignorée par les moteurs. Le seul changement pour les implémentations concerne la reconnaissance et la suppression des annotations de type partout où elles sont utilisées.
La proposition chercherait à établir un support annotant les types de paramètres, de variables et de propriétés de classe. Il envisagerait également d’ajouter un interface mot-clé, opérateurs d’assertion comme ! et aset un ? modificateur pour marquer les types comme facultatifs. L’intention est que tous ces éléments reflètent TypeScript ; comme pour toute proposition de l’étape 0, le résultat final peut cependant fonctionner différemment.
À quoi ça sert?
Si les annotations de type ne changent pas votre programme, la question évidente est de savoir si elles en valent la peine. La proposition soutient « oui » en raison de la capacité de la syntaxe à raccourcir les temps d’itération et à réduire la charge autour des chaînes d’outils JavaScript modernes.
L’écriture de code de type sécurisé nécessite actuellement l’utilisation de TypeScript, une version de langage différente qui ajoute des dépendances à votre projet et nécessite une étape de compilation manuelle. Ce code peut ensuite passer par d’autres outils tels qu’un module bundler et transpiler avant que votre JavaScript final ne soit produit pour distribution. Il s’ajoute à une chaîne d’outils complexe avec plusieurs pièces mobiles.
Bien que JavaScript soit un langage intrinsèquement faiblement typé, les avantages d’un typage fort sont désormais largement reconnus par la communauté. Cela ressort clairement de l’élan entourant le projet TypeScript. Le typage statique était également le leader incontesté de la question «caractéristique manquante» de l’enquête State of JS 2021.
L’ajout d’une syntaxe de type à JavaScript lui-même vous permettrait de bénéficier de certains des avantages de TypeScript sans avoir à compiler votre code. Cela simplifie la configuration et la maintenance du projet tout en faisant évoluer JavaScript pour mieux s’aligner sur les pratiques de développement modernes.
Au cours des dernières années, davantage de code a commencé à migrer vers une approche « JavaScript pur ». Le déclin des navigateurs hérités rend la transpilation moins nécessaire qu’elle ne l’était autrefois – la majorité des implémentations modernes offrent une prise en charge complète de fonctionnalités telles que les classes, les fonctions fléchées, les variables à portée de bloc et async/await. JavaScript possède même un système de modules à part entière qui fonctionne sur tous les moteurs, y compris dans les navigateurs.
Il y a quelques années seulement, une longue chaîne d’outils était obligatoire pour pouvoir écrire ces fonctionnalités dans votre code en toute confiance, cela fonctionnerait sur les appareils des utilisateurs. De nos jours, les développeurs peuvent mettre ces processus de construction de côté en toute sécurité, en revenant au modèle JavaScript original de référencement des fichiers avec <script> Mots clés.
Les types sont l’un des rares domaines restants de l’écosystème JavaScript qui ne sont pas pris en charge par le langage lui-même. Aimez-les ou détestez-les, il est indéniable que les types sont devenus partie intégrante du développement JavaScript pour de nombreuses équipes et projets. La proposition de syntaxe reconnaît formellement ce fait. Il tente d’apporter un certain degré de prise en charge des types à JavaScript sans casser le code existant ni appliquer des vérifications de type d’exécution qui nuisent aux performances.
Que doivent réellement faire les types ?
Le rôle d’un « type » varie selon les langues. Le démoninateur commun réside dans la capacité d’un type à exprimer le type de données qu’une variable particulière contiendra. Des significations, des capacités et des comportements supplémentaires sont ensuite superposés sur cette base.
Dans les langages compilés typés statiquement comme C# et Java, les types sont appliqués au moment de la compilation. Il est impossible de compiler un programme lorsque vous avez des incompatibilités de type dans votre code. Dans les langages interprétés avec un typage fort facultatif, dont PHP est un exemple, les types sont appliqués au moment de l’exécution – le programme génère une erreur lorsque le type d’une valeur est incompatible avec le contexte dans lequel elle est utilisée.
Un débat actif au sein de la communauté JavaScript a été de savoir jusqu’où les attributions de tout système de type intégré devraient s’étendre. Cette proposition limite son rôle à l’élément le plus fondamental, une simple documentation du type attendu d’une valeur. Cela correspond bien à la position de TypeScript en tant que syntaxe de type effaçable qui est ignorée lors de l’exécution.
Le but de ce modèle est de donner aux développeurs un retour instantané sur les bogues potentiels lorsqu’ils écrivent du code. Vous pouvez obtenir des informations sur les problèmes de type lorsque vous écrivez du JavaScript standard dans un IDE compatible. Si vous le souhaitez, vous pouvez également utiliser un outil de support tel que TypeScript, un analyseur statique ou un bundler pour auditer votre source à la demande. Cela pourrait bloquer un déploiement dans vos pipelines CI lorsqu’un problème de type est présent.
Le sentiment actuel est que ces fonctionnalités sont suffisantes pour aligner JavaScript sur les besoins les plus courants des développeurs. Les fonctionnalités trouvées dans d’autres langages, telles que l’introspection et la réflexion, ne sont généralement pas nécessaires dans l’écosystème JavaScript, en partie parce que les développeurs se sont habitués à l’approche d’effacement de TypeScript.
L’alternative existante : Docblocks
Il convient de noter qu’il existe déjà quelque chose de similaire à la syntaxe proposée pour les annotations effacées : les balises JSDoc familières sont couramment utilisées pour ajouter des détails de type au code JavaScript :
/** * @param name {string} * @param age {number} */ function sayAge(name, age) { console.log(`${name} is ${age} years old.`); }
Les commentaires JSDoc sont pris en charge par divers outils populaires. Cependant, ils ne sont pas une partie standardisée du langage et ils vous obligent à mélanger les détails du fonctionnement de votre code – ses types attendus – avec la documentation centrée sur l’homme comprenant le reste du docblock.
La syntaxe de JSDoc est également très détaillée. Outre les noms de balises requis, cela nécessite généralement la répétition d’éléments déjà existants dans votre code, tels que les noms de paramètres dans l’exemple ci-dessus. Si vous modifiez un paramètre dans la signature de la fonction, vous devez également penser à modifier la balise JSDoc.
La nouvelle proposition de syntaxe peut être fonctionnellement équivalente à docblocks mais elle offre une expérience beaucoup plus simplifiée. Les types se trouvent à côté de leurs cibles dans le cadre de votre source, plutôt que dans un docblock que vous devez créer et maintenir séparément.
Et après?
L’équipe TypeScript de Microsoft et des co-auteurs, dont Bloomberg, Igwalia et plusieurs contributeurs indépendants, ont soumis la proposition de l’étape 0 lors de la plénière du TC39 de mars 2022. La proposition est depuis passée à l’étape 1. L’acceptation est encore loin, la mise en œuvre à l’intérieur des moteurs n’arrivant potentiellement pas avant « des années ».
L’objectif principal de cette proposition est d’équilibrer la longue queue de code non typé de JavaScript avec la demande actuelle d’une expérience de développement plus typée statiquement. L’utilisation d’une syntaxe entièrement facultative effacée garantit la rétrocompatibilité, mais soulève la perspective qu’elle sera inefficace pour encourager l’adoption et consolider l’écosystème. Le débat autour de celui-ci devrait se développer avec de nouvelles opinions et perspectives à mesure que la proposition progresse dans la voie des normes.
