Dois-je .npmignorer mes tests?

Que dois-je mettre exactement .npmignore ?

Des tests? Des trucs comme .travis.yml, .jshintrc? Tout ce qui n'est pas nécessaire lors de l'exécution du module (sauf le readme)?

Je ne trouve aucune indication à ce sujet.

Comme vous l'avez probablement constaté, NPM n'indique pas vraiment ce qui devrait y entrer, mais plutôt une liste de fichiers ignorés par défaut . Beaucoup de gens ne l'utilisent même pas car tout ce qui se trouve dans votre .gitignoreest ignoré npmpar défaut s'il .npmignoren'existe pas. De plus, de nombreux fichiers sont déjà ignorés par défaut quels que soient les paramètres et certains fichiers sont toujours exclus de l'ignorance, comme indiqué dans le lien ci-dessus.

Il n'y a pas beaucoup d'officiel sur ce qui devrait toujours être là parce que c'est fondamentalement un sous-ensemble de .gitignore, mais d'après ce que je retiens de l'utilisation de node pendant 5 ans, voici ce que j'ai trouvé.

Remarque: Par production, j'entends tout moment où votre module est utilisé par quelqu'un et non pour se développer sur le module lui-même.

Pré-version des sources compilées croisées

• Avantages : Si vous utilisez un langage qui compile de manière croisée en JavaScript, vous pouvez précompiler avant la publication et ne pas inclure de .coffeefichiers dans votre package, mais continuer à les suivre dans votre référentiel git.

Construire les restes de fichiers

• Avantages : les personnes utilisant des éléments tels que node-gyppeuvent avoir des fichiers objets générés lors d'une construction qui ne devraient jamais entrer dans le package.
• Inconvénients : Cela devrait toujours entrer dans le de .gitignoretoute façon. Vous devez placer ces éléments ici si vous utilisez .npmignoredéjà un fichier car il remplace .gitignorele point de 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 dans le cas où il y aurait une défaillance spécifique au système, telle qu'une version obsolète du nœud en cours d'exécution qui entraîne l'échec d'un test.

Paramètres d'intégration continue / fichiers Meta

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

Documents et exemples de code non-readme

• 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 minimale dans votre Readme, votre module est trop volumineux.
• Inconvénients : les utilisateurs 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

• Pour : Vous n'avez certainement pas besoin de joncher vos versions avec des CNAMEfichiers ou des espaces réservés index.htmlsi vous utilisez votre module sert également de gh-pagesréférentiel à double fonction .

bower.json et amis

• Avantages : Si vous décidez de créer vos dépendances avant la publication, vous n'avez pas besoin que l'utilisateur final installe bower, puis installe plus de choses avec cela. Personnellement, je garderais ces trucs dans l'emballage. Quand je fais un npm install, je ne devrais compter que sur npm et aucune autre source externe.

En gros, vous devriez jamais l'utiliser s'il y a quelque chose que vous souhaitez garder hors de votre paquet npm mais pas en dehors de votre référentiel 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 gens coincés avec des objets non pertinents dans leur package.

Je suis d'accord avec la réponse courte et syntétique de Lante et la grande réponse de SamT :

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

Ma contribution à ces réponses:

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

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

Je pense que c'est plus simple, à l'épreuve du temps et que la sémantique est meilleure;)

Juste pour clarifier, à chaque fois que quelqu'un le fera npm install your-library, npm téléchargera tous les fichiers source inclus dans le dépôt, à l'exception des fichiers que vous incluez dans votre fichier .npmignore.

Sachez que les personnes installant votre bibliothèque n'auront besoin que de votre bibliothèque en cours d'exécution, rien d'autre ne sera nécessaire.

Par exemple, quand quelqu'un installe une bibliothèque, c'est probablement qu'il / elle ne se soucie pas de .travis.ymlvos .jshintrcfichiers ou de vos fichiers, ou même de certaines images, fichiers Grunt, documentation, etc.

.npmignore pourrait laisser votre package npm avoir moins de fichiers et être téléchargé plus rapidement

N'incluez pas vos tests. Souvent, les tests sont 5x la taille de la base de code réelle. Tant que vos tests sont sur Github, etc., cela suffit.

Mais ce que vous devez absolument faire est de tester votre package 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 en savoir plus sur le test de votre package après l'avoir archivé, ici: https://github.com/ORESoftware/r2g

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