Dois-je tester mes tests?

Comme vous l’avez probablement constaté, NPM n’indique pas précisément ce qui devrait s’y trouver, mais une liste de fichiers ignorés par défaut . Beaucoup de gens ne l’utilisent même pas car tout ce qui est dans votre .gitignore est ignoré par défaut dans npm si .npmignore n’existe pas. En outre, de nombreux fichiers sont déjà ignorés par défaut, quels que soient les parameters, et certains fichiers ne sont pas toujours pris en compte, comme indiqué dans le lien ci-dessus.

Il n’ya pas beaucoup d’officiel sur ce qui devrait toujours être là car c’est fondamentalement un sous-ensemble de .gitignore , mais de ce que j’ai .gitignore utilisant node pendant 5 ans, voici ce que j’ai trouvé.

Note: Par production, je veux dire à tout moment où votre module est utilisé par quelqu’un et ne pas se développer sur le module lui-même.

Pré-publication des sources compilées

• Avantages : Si vous utilisez un langage qui comstack de manière croisée dans JavaScript, vous pouvez le précomstackr avant la publication et ne pas inclure les fichiers .coffee dans votre paquet, mais continuer à les suivre dans votre repository git.

Construire les rests de fichiers

• Avantages : Les personnes utilisant des éléments tels que node-gyp peuvent avoir des fichiers objects générés lors d’une construction qui ne doivent jamais être node-gyp au package.
• Cons : Cela devrait toujours aller dans le .gitignore toute façon. Vous devez placer ces éléments ici si vous utilisez déjà un fichier .npmignore car il remplace le .gitignore du sharepoint vue de npm.

Des tests

• Avantages : Moins de bagages dans votre code de production.
• Inconvénients : vous ne pouvez pas exécuter de tests sur des environnements en direct si vous rencontrez un problème spécifique au système, comme une version obsolète du noeud en cours d’exécution qui provoque l’échec d’un test.

Paramètres d’continuous integration / méta fichiers

• Avantages : Encore une fois, moins de bagages. Des éléments tels que .travis.yml ne sont pas nécessaires pour utiliser, tester ou afficher le code.

Documents non-readme et exemples de code

• Avantages : Moins de bagages. Certaines personnes existent dans l’école de pensée où, si vous ne pouvez pas exprimer au moins une fonctionnalité viable minimum dans votre fichier Lisez-moi, votre module est trop gros.
• Inconvénients : les gens ne peuvent pas voir une documentation exhaustive et des exemples de code sur leur propre système de fichiers. Ils devraient visiter le référentiel (qui nécessite également une connexion Internet).

Objets Github-pages

• Avantages : Vous n’avez certainement pas besoin de stocker vos versions avec des fichiers CNAME ou un espace réservé index.html s si vous utilisez votre module qui sert également de double-repository en tant que référentiel gh-pages .

bower.json et ses amis

• Avantages : Si vous décidez d’intégrer vos dépendances avant la publication, vous n’avez pas besoin que l’utilisateur final installe bower, puis installe plus d’éléments avec cela. Je garderais personnellement ce genre de choses dans le paquet. Lorsque je fais une npm install , je ne devrais compter que sur npm et sur aucune autre source externe.

Fondamentalement, vous devriez toujours l’utiliser s’il y a quelque chose que vous souhaitez garder hors de votre paquet npm mais pas de votre repository npm. Ce n’est pas une longue liste d’éléments, mais npm préfère intégrer la fonctionnalité plutôt que d’avoir des personnes bloquées avec des objects non pertinents dans leur package.

Je suis d’accord avec la réponse courte et syntaxique de lante et la grande réponse de SamT :

• Vous ne devez pas inclure vos tests dans votre paquet.
• Votre package ne doit contenir que des fichiers d’exécution de production.
• Cela rendra votre téléchargement plus simple et plus rapide.

Ma consortingbution à ces réponses:

.npmignore est le moyen de la liste noire pour réaliser la sélection de fichier de package. Mais de manière plus pratique, vous pouvez inclure des fichiers de liste blanche que vous devez inclure dans votre paquet en utilisant le champ de fichiers de votre package.json:

 { "files": [ "lib/", "index.js" ] } 

Je pense que c’est plus simple, futur et avoir une meilleure sémantique;)

Juste pour clarifier, chaque fois que quelqu’un npm install your-library , npm télécharge tous les fichiers sources que le repository inclut, à l’exception des fichiers que vous incluez dans votre .npmignore .

Sachez que les personnes installant votre bibliothèque n’auront besoin que de votre bibliothèque, tout le rest ne sera pas nécessaire.

Par exemple, lorsque quelqu’un installe une bibliothèque, il est probable qu’il / elle ne se soucie pas de vos .travis.yml ou de vos fichiers .jshintrc , ou même de certaines images, fichiers Grunt, documentation, etc.

.npmignore pourrait permettre à votre paquet npm d’avoir moins de fichiers et plus rapide à télécharger

N’incluez pas vos tests. Souvent, les tests sont comme 5 fois la taille de la base de code réelle. Tant que vos tests sont Github, etc., ça suffit.

Mais vous devez absolument tester votre paquet NPM dans son format publié . Créez des tests de fumée qui résident dans la base de code réelle, mais ne font pas partie de la suite de tests.

Vous pouvez lire sur le test de votre paquet après l’avoir archivé, ici: https://github.com/ORESoftware/r2g

Comment tester un résultat `NPM publish ‘sans publier réellement sur NPM?