3 points par GN⁺ 2024-07-26 | 1 commentaires | Partager sur WhatsApp

Module : ajout de --experimental-strip-types

  • Exécution de fichiers TypeScript dans Node.js

    • Il est possible d’exécuter des fichiers TypeScript en activant le flag --experimental-strip-types
    • Node.js transforme le code source TypeScript en code source JavaScript
    • Aucune vérification de type n’est effectuée pendant la transformation, les types sont simplement supprimés
  • Motivation

    • Il est important de pouvoir exécuter des fichiers TypeScript sans dépendances externes ni loader
    • L’objectif est que les utilisateurs puissent lancer node foo.ts
  • Signification du type stripping

    • Le type stripping consiste à supprimer tous les types et à convertir l’entrée en module JavaScript
    • Exemple : const foo: string = "foo"; est transformé en const foo = "foo";
  • Pourquoi le choix de @swc/wasm-typescript

    • Pour sa simplicité
    • D’autres outils nécessitent d’ajouter Rust ou Go, tandis que @swc/wasm-typescript ne requiert qu’un petit package avec des fichiers wasm et js
    • Il est aussi utilisé par Deno, ce qui le rend fiable
  • Limites

    • Les fonctionnalités propres à TypeScript comme les enums et les namespaces ne sont pas transformées
    • Les imports sans extension ne sont pas pris en charge
  • Plans à venir

    • Une implémentation dans la couche native est possible
    • La prise en charge des source maps pourrait être ajoutée

Résumé de GN⁺

  • Présentation d’une nouvelle fonctionnalité permettant d’exécuter des fichiers TypeScript dans Node.js
  • Les fichiers TypeScript peuvent être exécutés après transformation en JavaScript, sans vérification de type
  • Cela simplifie l’environnement de développement en permettant d’exécuter des fichiers TypeScript sans dépendances externes
  • Cette fonctionnalité est implémentée avec @swc/wasm-typescript, avec une éventuelle implémentation future dans la couche native
  • Elle peut être utile pour les projets qui mélangent TypeScript et JavaScript.

1 commentaires

 
GN⁺ 2024-07-26
Avis Hacker News
  • Supprimer les types de TypeScript est impossible sans la syntaxe propre à TypeScript. L’effacement des types n’est pas une opération au niveau des tokens, et la syntaxe TypeScript continue d’évoluer

    • Par exemple, foo < bar & baz > ( x ) était interprété différemment dans TypeScript 1.5
    • Pour utiliser les nouvelles fonctionnalités de TypeScript, il faut compiler vers du JS ou garder Node à jour
    • Pour ceux qui utilisent les versions LTS de Node, le compromis peut être difficile
  • Si Node.js pouvait exécuter directement des fichiers TypeScript, le compilateur TypeScript n’aurait pas besoin de supprimer les types et de convertir en JavaScript

    • Cela ressemble à la situation de Python
    • En Python, il existe plusieurs vérificateurs de types, qui utilisent tous la même syntaxe d’annotations de type mais lui donnent des significations différentes
    • En JavaScript, TypeScript est devenu le seul vérificateur de types vraiment populaire
    • En Python, certains utilisent aussi les annotations de type comme de simples commentaires
    • Si Node.js prenait en charge le fait d’ignorer les types, cela serait aussi possible en JavaScript
  • Je me demande comment l’écosystème NPM réagirait si cette fonctionnalité devenait le comportement par défaut

    • Lors de la publication de modules NPM, continuerait-on à construire des versions CJS et EJS, ou bien ajouterait-on engine: nodejs >= 25 dans package.json en supprimant l’étape de build ?
    • Personnellement, j’aimerais que les modules NPM écrits en TS ne fournissent plus de dist/.cjs
    • Supprimer l’étape de build serait tentant pour les contributeurs NPM
    • Cela pourrait avoir des effets en chaîne dans l’écosystème NPM
    • Si Node.js proposait cette fonctionnalité sans drapeau expérimental, on peut s’attendre à ce que tous les consommateurs acceptent les fichiers TS
    • Cela pourrait aussi forcer Firefox et Safari à accepter les fichiers TS
    • Personnellement, je serais heureux que le compilateur JS se contente de jeter les annotations de type TS
    • Si Node accepte les fichiers .ts, on peut supprimer l’étape de transpilation
  • Ce serait un énorme gain si Node pouvait inspecter les types depuis le JS

    • En Python, il existe des outils comme pydantic, qui inspectent les types et génèrent des validations
    • Cela permet, avec une notation standard unique, de faire de la vérification de types, de la validation de données à l’exécution, de la génération d’API et de la documentation d’API
    • Aujourd’hui, en JS, il faut des outils comme zod
  • L’expérience développeur (DX) de Bun est sans précédent dans ce domaine, et couvre la plupart des cas d’usage

    • Dans Node, on ne peut pas configurer l’absence d’obligation d’extension à l’import, et on ne peut pas non plus configurer tsc pour qu’il ajoute automatiquement les extensions .js
    • Un support TypeScript natif pourrait résoudre cela, mais il sera difficile d’égaler l’expérience utilisateur ou les performances de Bun
  • J’adore TypeScript et j’attends depuis longtemps un runtime TypeScript

    • J’ai quitté Java parce que je voulais un système de types plus riche et un typage progressif
    • Malgré les défauts de l’écosystème npm, utiliser des bibliothèques reste moins pénible et plus amusant
    • Rust se situe ailleurs dans le spectre des langages, mais procure une sensation similaire
    • JIT était un mauvais terme ; je voulais parler des différences de temps de démarrage et d’exécution entre la JVM et V8
  • Ma fonctionnalité préférée de deno arrive directement dans Node

    • Je suis très enthousiaste à l’idée de pouvoir supprimer les types sans installer esbuild
    • Ces derniers temps, je préférais Python, mais TypeScript est meilleur que Python sur le plan des types
    • Les gros scripts bénéficient davantage de la présence de types
  • Cela a été un mois très important pour Node

    • La v22.5.0 a ajouté node:sqlite, et maintenant le support TypeScript arrive
    • J’aime la direction que prend Node
  • Je suis l’auteur de la PR, AMA

  • J’ai commencé à utiliser Node.js pour le backend il y a longtemps, et cela offrait beaucoup d’avantages par rapport à PHP

    • Node restait assez pénible et il fallait l’assembler pour en faire le langage qu’on voulait
    • J’ai commencé à utiliser Golang, et la sûreté des types a rendu le développement plus simple
    • TypeScript est une bonne option, mais cela reste juste un ajout de plus
    • Le grand avantage de Node, c’est la rapidité de prototypage, et l’usage de TypeScript peut annuler cet avantage