Node.js n'a pas implémenté TypeScript

Un bref article sur les raisons pour lesquelles Node.js n'a pas implémenté TypeScript.

Tout d'abord

Ce qui suit est une explication de ce a été et de ce n'a pas été fait dans Node.js concernant TypeScript.

Cet article n'a pas pour but d'être une critique de l'équipe Node.js ou de l'équipe TypeScript.

En fait, c'est tout le contraire.

Je pense sérieusement que l'équipe Node.js a fait le meilleur choix possible en "implémentant" TypeScript comme elle l'a fait.

Ce que j'insiste vraiment ici, c'est que Node.js n'a pas implémenté TypeScript. Ils ont simplement ajouté une sorte de support. Il s'agit d'une distinction cruciale qui, à mon avis, est souvent négligée dans les discussions sur Node.js et TypeScript.

Au cours des dernières semaines, j'ai compté plus de 50 articles cités dans les newsletters que j'ai lues et mentionnant que Node.js avait implémenté TypeScript.

Je pense qu'il est temps de clarifier ce point une fois pour toutes.

Alerte spoiler : Node.js n'a pas implémenté TypeScript.

TypeScript : un bref historique et quelques données

En 2010, Microsoft a publié TypeScript, un sur-ensemble de JavaScript qui ajoute un typage statique au langage. TypeScript a été conçu pour remédier à certaines des lacunes de JavaScript, telles que le manque de sécurité des types et la difficulté de maintenir de grandes bases de code. Depuis sa sortie, TypeScript a gagné en popularité parmi les développeurs, de nombreux projets l'adoptant comme langage principal.

Selon la dernière enquête State Of JS, TypeScript est pratiquement partout. 78 % des développeurs utilisent TypeScript pendant au moins 50 % de leur temps de développement, il n'est donc pas étonnant que l'écho de "Node.js implémente TypeScript" ait atteint même les recoins les plus profonds du Web.

Mais, pour être clair, cela ne s'est pas produit. Et ce ne sera probablement jamais le cas.

Les problèmes

Il y a plusieurs raisons pour lesquelles Node.js n'a pas implémenté TypeScript. Voici ce que je pense être les deux plus importants :

#1 : TypeScript injecte des éléments au moment de l'exécution.

Saviez-vous ce que devient une énumération au moment de l'exécution ? Un objet.

Et ce n'est qu'un des rares exemples - heureusement - de la façon dont TypeScript injecte des éléments au moment de l'exécution. C'est un problème pour Node.js car cela signifierait que le runtime devrait être conscient des fonctionnalités de TypeScript, ce qui introduirait beaucoup de complexité et de surcharge.

Si Node.js souhaite conserver sa cohérence avec ECMAScript et ne pas avoir à gérer les dépendances pour le reste de son existence, il ne peut pas accepter TypeScript comme dépendance sous la forme actuelle.

#2 : Gestion des versions sémantiques.

TypeScript ne suit pas le versioning sémantique (semver).

Node.js, en revanche, suit strictement Semver et propose trois lignes de version différentes (actuellement, nous avons 18.x, 20.x, 22.x). Cela signifie que des modifications importantes peuvent être introduites dans des versions mineures ou des correctifs, ce qui peut entraîner des problèmes de compatibilité avec le code existant.

De plus, le nombre de plateformes prises en charge est énorme, il n'est donc pas facile de tout garder sous contrôle.

Node.js ne peut tout simplement pas accepter TypeScript comme dépendance car cela briserait Semver. Il s'agit d'un problème fondamental qui empêche Node.js d'implémenter TypeScript.

Alors, qu’ont-ils fait ?

C'est là que la confusion surgit. Node.js n'a pas implémenté TypeScript, mais ils ont ajouté la suppression de type sous un indicateur expérimental. Cette fonctionnalité permet aux développeurs d'écrire du code TypeScript et de le compiler en JavaScript sans les informations de type. Il s'agit d'un compromis qui permet aux développeurs d'utiliser TypeScript dans Node.js sans introduire les problèmes mentionnés ci-dessus.

Vous voulez un exemple ? Voilà :

function sum(a: number, b: number): number {
  return a + b;
}

Cette fonction, une fois compilée avec l'indicateur --experimental-strip-types, deviendra :

function sum(a        , b        )         {
  return a + b;
}

Vous avez vu ça ? Les types ont disparu et ont été remplacés par des espaces. Mais pourquoi ?, pourriez-vous demander. Eh bien, parce que cela préserve les références aux sourcesmaps sans avoir à avoir un processus de construction distinct pour celles-ci.

En interne, cela se fait via un package appelé amaro qui enveloppe swc - un outil de construction bien connu qui effectue le décapage proprement dit.

Bien sûr, des limitations existent, telles que l'impossibilité d'utiliser des fonctionnalités spécifiques à TypeScript comme les énumérations mentionnées précédemment. Mais c'est quand même un grand pas en avant d'empêcher les gens d'écrire 135 fichiers de configuration pour qu'une fonction de somme accepte deux nombres et en renvoie un troisième.

Ciao,
Michel.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!