Podcast : Est-ce que npm est mauvais pour le JavaScript

Dans ce podcast nous allons parler de npm et de son impact sur l'écosystème JavaScript afin d'essayer de répondre à ma question "est-ce que npm est néfaste pour le JavaScript ?"

Pourquoi cette réflexion

Aujour'hui lorsque l'on souhaite travailler sur du JavaScript côté front-end on se retrouve à interagir avec le gestionnaire de paquets npm pour gérer les dépendances. Initialement pensé pour NodeJS, son utilisation a été détourné par les bundlers qui ont commencés à l'utiliser pour les dépendances front. Pourquoi est-ce un problème ?

• npm ne dispose pas d'un système d'organisation qui permet de différencier facilement les librairies destinnées à l'écosystème NodeJS des librairies destinées aux navigateurs.
• Aucun tag ne permet de spécifier la version de l'ECMAScript utilisée et on se retrouve à mélanger de l'ES2022 avec de l'ES5.
• Aucune distinction n'est faite entre les paquets qui utilise un système de module EcmaScript et ceux qui utilisent encore CommonJS.
• Contrairement à d'autres gestionnaires de paquets qui utilisent un dépôt git comme base lors du déploiement, npm incite à déployer du code de manière plus arbitraire. Ce code est souvent le fruit d'outils de builds qui rendent le code peu lisible ce qui nuit à l'audit et au déboguage.
• Les dépendances ne sont pas applaties et on peut se retrouver avec dix version d'un même paquet (ce qui a un impact forcément négatif sur le poid en front).
• Les noms des dépendances ne sont pas prefixées par un nom d'organisation (comme c'est le cas sur Composer par exemple) ce qui rend difficile l'identification d'un auteur de confiance.

On propose quoi ?

Personnelement je pense que la solution idéale serait la création d'un gestionnaire de paquet destiné au front-end. Ceci permettrait de partir sur des bases modernes (un peu comme ce qu'a tenté de faire pika.dev).

Une solution moins disruptive serait d'apporter des modifications à l'écosystème actuel pour essayer de mitiger les problèmes cités plus haut.

• Afficher les peerdeps directement sur npmjs.
• Ajouter une nouvelle clef "browsers" dans le package.json qui permettrait de spécifier les navigateurs supportés par la librairie. Cette clef permettrait aussi d'indiquer que la librairie est pensée pour les navigateurs.
• Ajouter une clef pour spécifier la version de l'ecmascript utilisé dans le code de la librairie (ou détecter cela automatiquement).
• Permettre de voir le code du paquet directement depuis npmjs.
• Eviter le principe du point d'entré unique et permettre de spécifier plusieurs fichiers plutôt que d'avoir un seul "main" qui exporte tout (cela éviterait d'avoir à faire ensuite du tree shaking).