Dois-je publier le code source de mon module sur npm ?

Question

J'espère que cette question ne sera pas trop orientée vers l'opinion publique. Je m'interroge sur les pratiques les meilleures et les plus courantes dans ce domaine.

Je publie un module npm écrit en ES6 et transposé en ES5 et UMD à l'aide de babel y enroulement .

La structure du fichier pourrait être résumée comme suit :

/coverage/
/dist/
/node_modules/
/src/
/test/
/tools/
.editorconfig
.eslintrc
.gitattributes
.gitignore
.travis.yml
CHANGELOG.md
CONTRIBUTING.md
LICENSE.txt
package.json
README.md

Le code source se trouve dans /src/ et le code compilé dans /dist/ .
Ces répertoires sont des .gitignored :

• couverture
• dist
• modules de nœuds

Ce que l'utilisateur utilisera réellement est en effet le contenu de /dist/ .

J'ai utilisé un kit de démarrage avec un processus de construction qui.. :

1. prend l'original package.json
2. supprime tous les scripts et les champs liés au développement de celui-ci
3. le copie dans dist
4. copie aussi les fichiers LICENSE et README dans dist (intact)

L'ensemble des sources du paquet sera publié sur GitHub, mais je ne suis pas sûr de ce que cela signifie. ce qu'il faut publier sur npm :

A) la structure entière du fichier (en supprimant /coverage/ y /node_modules/ ) avec un niveau supérieur package.json qui a un point d'entrée vers le fichier pertinent dans dist

o

B) publier simplement le contenu de dist avec une version dépouillée package.json et le README & LICENSE. Je sais que la simple publication du contenu de /dist rendrait les cartes sources inutiles.

Quelle est la pratique courante ici ?

Answer 1

À mon avis, la meilleure pratique consiste à publier le code minifié dans le fichier dist et aussi le code source dans src dossier. Il faut également inclure d'autres fichiers tels que package.json , package-lock.json , README.md , LICENSE.txt , CONTRIBUTING.md etc. qui se trouvent dans le répertoire racine du paquet. Pour cela, il faut utiliser files dans le champ package.json pour mettre sur liste blanche ce qui doit être publié sur npm au lieu de trouver ce qui n'a pas à être publié en établissant une liste noire en .npmignore . Le site dist ne devrait contenir que le paquet minifié et il n'est pas nécessaire de générer un autre fichier package.json dans le dossier dist en supprimant scripts, devDependencies etc. En effet, lorsque le consommateur du paquet fait npm install <package name> il installe uniquement les paquets contenus dans dependencies et ignore les paquets sous devDependecies .

Les fichiers minifiés peuvent être utilisés par le navigateur en se référant directement à la balise scripts où le temps de chargement sera plus petit en raison de la petite taille du fichier alors que les frameworks modernes tels que angular utilisera du code non miniaturisé. Les frameworks modernes ont leur propre outil de construction comme webpack pour réduire le code.

Il n'est pas nécessaire d'avoir un niveau supérieur package.json qui a un point d'entrée dans le main vers le fichier correspondant dans dist . Au lieu de cela, à mon avis, le niveau supérieur package.json devrait avoir un point d'entrée vers un fichier pertinent tel que index.js au même niveau du paquet Root.

Enfin, on peut exécuter npm pack pour voir ce qu'il y a à l'intérieur de l'archive et enfin faire npm publish au registre npm pour une utilisation publique à partir du dossier du paquet Root.

Answer 2

La pratique courante est d'avoir un code source sur npm, et non le résultat d'une transpilation/minification/etc. Il est également courant de publier des modules qui n'ont pas besoin de transpilation en premier lieu.

Si votre module ne peut pas être utilisé directement dans Node sans transpilation (ce qui serait très inhabituel pour un module sur npm et certainement pas attendu), alors vous devez soit vous assurer qu'il est transpilé lors de l'installation (ce qui est délicat et peut corrompre le système de fichiers de l'utilisateur si cela est mal fait), soit inclure le fichier dist dans vos modules publiés.

Si vous voulez inclure le dist dans le module publié, vous devez vous assurer que le bon fichier est chargé lorsque les utilisateurs ont besoin de votre module et que vous construisez toujours une nouvelle version du module. dist avant de faire npm version y npm publish .

Mon conseil, cependant, serait d'écrire vos modules Node dans Node. De cette façon, ils seront utilisables directement avec un petit téléchargement, une installation rapide, aucun problème de transpilation et des messages d'erreur lisibles - la dernière partie est très importante lors du débogage.

La publication de code transpilé pose un problème sérieux qui est souvent négligé. Publier du code qui diffère de quelque manière que ce soit du code source réel, qu'il soit transpilé, minifié ou obscurci de quelque manière que ce soit, a des implications en matière de sécurité. Il est très difficile de vérifier les résultats de la transpilation et vous devez le faire si c'est le code qui est réellement exécuté (surtout si vous ne l'avez pas transpilé vous-même).