Désormais, ce sera ESM uniquement.

Jusqu’à récemment, j’étais opposé à la transition brutale de toutes les bibliothèques JavaScript vers ESM. Mais comme les technologies liées à ESM et leur adoption progressent de jour en jour, j’espère désormais que tous les développeurs passeront à ESM. Voici pourquoi.

Pourquoi

• Des outils prêts à l’emploi
  • De nombreux outils sont apparus pour faciliter la transition vers ESM, comme Vite, ESLint et tsx.
  • Il n’est pas simple pour l’approche historique des bibliothèques (CJS) de dépendre d’ESM, qui est l’approche moderne ; il faut donc aller de l’avant pour préparer l’avenir.
  • Une méthode a été développée dans les versions récentes de Node.js pour charger des bibliothèques ESM avec la fonction require(), ce qui facilite encore l’adoption d’ESM.
• Le problème du double support
  • Les différences de conception entre les deux approches étant marquées, leur interopérabilité reste très limitée.
  • Les utilisateurs doivent vérifier un par un si ESM est pris en charge, ce qui ajoute une contrainte inutile.
  • Comme il faut prendre en charge les deux approches, la taille des paquets devient beaucoup plus importante.

Quand faut-il changer ?

• Pour les nouveaux paquets, passez systématiquement à ESM.
• Pour les bibliothèques destinées au navigateur, cela permet de produire des bundles plus légers.
• Pour les programmes CLI aussi, cela peut aider leurs utilisateurs à migrer naturellement vers ESM.
• Mais avant cela, il est important de connaître l’état des bibliothèques dont vous dépendez déjà ainsi que les exigences de vos utilisateurs.

Jusqu’où faut-il aller ?

J’ai créé un analyseur de dépendances pour comprendre les dépendances d’une bibliothèque. Il permet de voir l’état des bibliothèques dont elle dépend ainsi que l’impact d’un passage à ESM.

La suite

Je prévois de convertir progressivement à ESM les paquets que je maintiens et d’examiner leurs dépendances en détail. J’ai également de nombreuses idées intéressantes autour de node-modules-inspector, afin d’apporter des informations plus utiles et d’aider à trouver les meilleures approches à l’avenir.

J’espère voir émerger un écosystème JavaScript/TypeScript plus léger, plus flexible et mieux optimisé. J’espère que cela vous aura été utile.