¿Debo .npmignore mis pruebas?

¿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.

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.

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

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

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?