web-dev-qa-db-fra.com

Devrais-je .npmignore mes tests?

Que dois-je exactement mettre dans .npmignore?

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

Je ne trouve aucune indication à ce sujet.

node.jsnpmnpmignore
79
callum

Comme vous l'avez probablement constaté, NPM n'indique pas précisément ce qui doit y figurer, mais dispose d'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 .gitignore est ignoré dans npm par défaut si .npmignore n'existe pas. En outre, de nombreux fichiers sont déjà ignorés par défaut, quels que soient les paramètres, et certains fichiers sont toujours exclus, comme indiqué dans le lien ci-dessus.

Il n’ya pas beaucoup d’officiels sur ce qui devrait toujours être là car c’est essentiellement un sous-ensemble de .gitignore, mais de ce que je déduis de l’utilisation du noeud pendant 5 ans, voici ce que j’ai proposé.

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

Publication préalable de sources compilées de différentes manières

  • Pros: si vous utilisez un langage qui compile de manière croisée dans JavaScript, vous pouvez précompiler avant la publication et ne pas inclure les fichiers .coffee dans votre paquet, mais les suivre dans votre référentiel git.

Construire des restes de fichier

  • Pros: les personnes utilisant des éléments tels que node-gyp peuvent avoir des fichiers objet générés lors d'une construction qui ne devraient jamais être insérés dans le paquet.
  • Cons: Cela devrait toujours aller dans le .gitignore de toute façon. Vous devez placer ces éléments ici si vous utilisez déjà un fichier .npmignore car il remplace .gitignore du point de vue de npm.

Des tests

  • Pros: Moins de bagages dans votre code de production.
  • Cons: vous ne pouvez pas exécuter de tests sur des environnements en direct sans la moindre chance qu'il y ait un échec spécifique au système, tel qu'une version obsolète du noeud en cours d'exécution qui entraîne l'échec d'un test. 

Paramètres d'intégration continue/méta-fichiers

  • Pros: 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-lisez-moi et exemples de code

  • Pros: Moins de bagages. Certaines personnes existent dans l’école de la pensée où, si vous ne pouvez pas exprimer au moins une fonctionnalité minimale viable dans votre fichier Lisez-moi, votre module est trop volumineux.
  • Cons: les utilisateurs ne peuvent pas consulter une documentation exhaustive et des exemples de code sur leur propre système de fichiers. Ils devront visiter le référentiel (ce qui nécessite également une connexion Internet).

Objets Github-pages

  • Pros: Vous n'avez certainement pas besoin de compléter vos éditions avec des fichiers CNAME ou un espace réservé index.htmls si vous utilisez votre module sert également de référentiel gh-pages.

bower.json et ses amis

  • Pros: Si vous décidez de créer vos dépendances avant leur publication, vous n'avez pas besoin que l'utilisateur final installe bower, mais installez davantage de choses avec cela. Personnellement, je garderais ce matériel dans l'emballage. Quand je fais un npm install, je ne devrais me fier qu’à npm et à aucune autre source externe.

En principe, vous devriez ne jamais l’utiliser si vous souhaitez conserver quelque chose en dehors de votre paquet npm mais pas de votre référentiel npm. Ce n'est pas une longue liste d'éléments, mais npm préférerait intégrer la fonctionnalité plutôt que d'avoir des personnes bloquées avec des objets non pertinents dans leur package.

76
SamT

Je suis d'accord avec la réponse courte et synthé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 paquet plus simple et plus rapide à télécharger.

Ma contribution à ces réponses:

.npmignore est le moyen blacklist de parvenir à la sélection du fichier de package. Mais de manière plus pratique, vous pouvez liste blanche les fichiers à inclure dans votre paquet en utilisant le champ files de votre paquet.json:

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

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

51
Yves M.

Pour clarifier, à chaque fois que quelqu'un npm install your-library, npm télécharge tous les fichiers source inclus dans le référentiel, à 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 en cours d’exécution, aucune autre opération ne sera nécessaire.

Par exemple, quand quelqu'un installe une bibliothèque, c'est probablement qu'il ne se soucie pas de vos fichiers .travis.yml ou .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

15
lante

N'incluez pas vos tests. Souvent, les tests correspondent à 5 fois la taille du code réel. Tant que vos tests sont Github, etc., c'est suffisant.

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 en savoir plus 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 réellement publier sur NPM?

0
Alexander Mills