¿Debo .npmignore mis pruebas?


91

¿Qué debo poner exactamente .npmignore?

Pruebas Cosas por el estilo .travis.yml, .jshintrc? ¿Algo que no sea necesario al ejecutar el módulo (excepto el archivo Léame)?

No puedo encontrar ninguna orientación sobre esto.


4
debería ignorar todo lo que no es necesario cuando alguien llama npm install yourlibrary, por ejemplo .travis.ymly.jshintrc
lante

¿De Verdad? incluso un archivo Léame? ¿Se recomienda esto oficialmente en algún lugar?
callum

2
README se incluye automáticamente independientemente de .npmignoreo "files"( docs.npmjs.com/files/package.json#files ).
Nicolás Fantone

Respuestas:


86

Como probablemente descubrió, NPM realmente no establece específicamente qué debería ir allí, sino que tiene una lista de archivos ignorados por defecto . Mucha gente ni siquiera lo usa, ya que todo en su .gitignorese ignora npmde forma predeterminada si .npmignoreno existe. Además, muchos archivos ya se ignoran de forma predeterminada independientemente de la configuración y algunos archivos siempre se excluyen para que no se ignoren, como se describe en el enlace anterior.

No hay mucha información oficial sobre lo que siempre debería estar ahí porque es básicamente un subconjunto de .gitignore, pero por lo que deduzco del uso de node durante 5 años, esto es lo que se me ocurrió.

Nota: Por producción me refiero a cualquier momento en el que alguien utilice su módulo y no se desarrolle en el módulo en sí.


Fuentes compiladas cruzadas antes del lanzamiento

  • Ventajas : si está utilizando un lenguaje que se compila de forma cruzada en JavaScript, puede precompilar antes del lanzamiento y no incluir .coffeearchivos en su paquete, pero seguir rastreándolos en su repositorio de git.

Construir restos de archivos

  • Ventajas : las personas que usan cosas como node-gyppodrían tener archivos de objetos que se generan durante una compilación que nunca deberían incluirse en el paquete.
  • Contras : Esto siempre debería ir en el de .gitignoretodos modos. Debe colocar estas cosas aquí dentro si ya está utilizando un .npmignorearchivo, ya que anula .gitignoredesde el punto de vista de npm.

Pruebas

  • Ventajas : menos equipaje en su código de producción.
  • Contras : No puede ejecutar pruebas en entornos en vivo con la mínima posibilidad de que haya una falla específica del sistema, como una versión desactualizada del nodo en ejecución que hace que una prueba falle.

Configuración de integración continua / archivos Meta

  • Ventajas : Una vez más, menos equipaje. Cosas como .travis.ymlno son necesarias para usar, probar o ver el código.

Documentos que no son Léame y ejemplos de código

  • Ventajas : Menos equipaje. Algunas personas existen en la escuela de pensamiento donde si no puede expresar al menos una funcionalidad mínima viable en su Léame, su módulo es demasiado grande.
  • Contras : la gente no puede ver documentación exhaustiva y ejemplos de código en su propio sistema de archivos. Tendrían que visitar el repositorio (que también requiere una conexión a Internet).

Objetos de Github-pages

  • Ventajas : Ciertamente, no es necesario que llene sus versiones con CNAMEarchivos o marcadores de posición index.htmlsi usa su módulo que también tiene una doble función como gh-pagesrepositorio.

bower.json y amigos

  • Ventajas : si decide construir sus dependencias antes del lanzamiento, no necesita que el usuario final instale bower y luego instale más cosas con eso. Personalmente, guardaría esas cosas en el paquete. Cuando hago una npm install, solo debería confiar en npm y no en otras fuentes externas.

Básicamente, debería usarlo si hay algo que desea mantener fuera de su paquete npm pero no fuera de su repositorio npm. No es una lista larga de elementos, pero npm preferiría incorporar la funcionalidad a que la gente se quede con objetos irrelevantes en su paquete.


¿No hay alguna forma de eliminar los scripts no utilizables del archivo package.json? Por ejemplo, ¿probar scripts? Me siento un poco desordenado para eliminar todo, pero mantener los scripts en el archivo ...
inf3rno

No no hay. Puede omitirlos del package.json ya que de todos modos es principalmente para NPM y si solo está ejecutando pruebas, puede acceder a ellos a través del comando original para ejecutarlos.
SamT

64

Estoy de acuerdo con la respuesta breve y sintética de lante y la gran respuesta de SamT :

  • No debe incluir sus pruebas en su paquete.
  • Su paquete solo debe contener archivos de tiempo de ejecución de producción.
  • Eso hará que su paquete sea más sencillo y más rápido de descargar.

Mi contribución a esas respuestas:

.npmignore es la forma de lista negra para lograr la selección de archivos de paquetes. Pero de una manera más práctica, puede incluir en la lista blanca los archivos que necesita incluir en su paquete usando el campo de archivos en su package.json:

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

Creo que es más simple, a prueba de futuro y tiene una mejor semántica;)


3
... por no hablar de más fácil de recordar y menos propenso a sufrir accidentes de uso (si eres tan olvidadizo como yo puedo ser). Gracias por el consejo, esto es genial.
Connor

2
Me gusta este enfoque.
Brady Holt

2
Creo que incluso puede omitir el "index.js" asumiendo que es el archivo 'principal' en su package.json :)
Ben George

Ignorar imágenes y documentos innecesarios está bien. Pero ignorar las pruebas probablemente no sea una buena idea. Descargar algunas KB adicionales no toma tanto tiempo y hacer un recursivo npm testen todos los node_modules puede darle una pista si algo funciona de manera diferente en un entorno determinado.
adelriosantiago

3
@ NicolásFantone La propiedad de los archivos también acepta el patrón glob . Entonces podemos ignorar los archivos de prueba sin crear .npmignore. files: ["lib", "!lib/**/*.test.js"]. :)
Sureshraj

15

Solo para aclarar, cada vez que alguien lo haga npm install your-library, npm descargará todos los archivos de origen que incluye el repositorio, excepto los archivos que incluya en su .npmignore.

Sepa que las personas que instalan su biblioteca solo necesitarán que su biblioteca esté en funcionamiento, no será necesario nada más.

Por ejemplo, cuando alguien instala una biblioteca, es probable que no le importen .travis.ymlsus .jshintrcarchivos o sus archivos, o incluso algunas imágenes, archivos Grunt, documentación, etc.

.npmignore podría permitir que su paquete npm tenga menos archivos y se descargue más rápido


1
El sentimiento aquí es bueno, pero para aclarar: .npmignoreno afecta directamente lo que se descarga , afecta lo que entra en su paquete cuando publica y carga npm . Esto indirectamente crea archivos más pequeños para descargar.
Mark Stosberg

2

No incluya sus pruebas. A menudo, las pruebas son como 5 veces el tamaño del código base real. Siempre que sus pruebas estén en Github, etc., eso es lo suficientemente bueno.

Pero lo que debe hacer es probar su paquete NPM en su formato publicado . Cree algunas pruebas de humo que residan en la base de código real, pero que no formen parte del conjunto de pruebas.

Puede leer sobre cómo probar su paquete después de cargarlo, aquí: https://github.com/ORESoftware/r2g

¿Cómo probar un resultado de `npm publish`, sin publicarlo en NPM?

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.