Dois-je .npmignorer mes tests?

91

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.

node.js  npm  npmignore 
— callum
source
4
devrait ignorer tout ce qui n'est pas nécessaire lorsque quelqu'un appelle npm install yourlibrary, par exemple .travis.ymlet.jshintrc
— lante
vraiment? même un readme? est-ce recommandé officiellement n'importe où?
— callum
2
README est automatiquement inclus indépendamment de .npmignoreou "files"( docs.npmjs.com/files/package.json#files ).
— Nicolás Fantone

Réponses:

86

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.

— SamT
source
N'existe-t-il pas un moyen de supprimer les scripts non utilisables du fichier package.json. Par exemple, tester des scripts? Je me sens un peu compliqué de tout supprimer mais de garder les scripts dans le fichier ...
— inf3rno
Non, il n'y en a pas. Vous pouvez les omettre du package.json car c'est principalement pour NPM de toute façon et si vous n'exécutez que des tests, vous pouvez y accéder via la commande d'origine pour les exécuter.
— SamT
64

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;)

— Yves M.
source
3
... pour ne rien dire de plus facile à retenir et moins sujette aux accidents (si vous êtes aussi oublieux que possible). Merci pour la pointe, c'est génial.
— Connor
2
J'aime cette approche.
— Brady Holt
2
Je pense que vous pouvez même omettre le "index.js" en supposant qu'il s'agit du fichier "principal" de votre package.json :)
— Ben George
Ignorer les images et les documents inutiles est très bien. Mais ignorer les tests n'est probablement pas une bonne idée. Le téléchargement de quelques KB supplémentaires ne prend pas beaucoup de temps et faire une récursive npm testsur tous les node_modules peut vous donner un indice si quelque chose fonctionne différemment dans un certain environnement.
— adelriosantiago
3
@ NicolásFantone La propriété files accepte également le modèle glob . Nous pouvons donc ignorer les fichiers de test sans créer .npmignore. files: ["lib", "!lib/**/*.test.js"]. :)
— Sureshraj
15

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

— lante
source
1
Le sentiment ici est bon, mais pour clarifier: .npmignoren'affecte pas directement ce qui est téléchargé , cela affecte ce qui entre dans votre package lorsque vous publiez et téléchargez. Cela crée indirectement des fichiers plus petits à télécharger.
— Mark Stosberg
2

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?

— Alexander Mills
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.