Pregunta ¿Debo anular mis pruebas?


¿Qué debería poner exactamente? .npmignore?

Pruebas? Cosas como .travis.yml, .jshintrc? ¿Algo que no se necesita al ejecutar el módulo (excepto el archivo Léame)?

No puedo encontrar ninguna guía sobre esto.


76
2017-08-04 18:05


origen


Respuestas:


Como probablemente hayas encontrado, NPM no dice específicamente qué debería ir allí, sino que tienen un lista de archivos ignorados por defecto. Muchas personas ni siquiera lo usan como todo en su .gitignore es ignorado en npm por defecto si .npmignore no existe Además, muchos archivos ya se ignoran por defecto, independientemente de la configuración, y algunos archivos siempre se excluyen de ser ignorados, como se indica en el enlace de arriba.

No hay mucho oficial sobre lo que siempre debería estar allí porque es básicamente un subconjunto de .gitignore, pero por lo que he deducido del uso de nodos durante 5 años, esto es lo que se me ocurrió.

Nota: Por producción Me refiero a cualquier momento en que tu módulo sea utilizado por alguien y no se desarrolle en el módulo mismo.


Fuentes compiladas cruzadas de prelanzamiento

Pros: Si está utilizando un lenguaje que compila en forma cruzada en JavaScript, puede precompilar antes del lanzamiento y no incluir .coffee archivos en su paquete pero sigan rastreándolos en su repositorio de git.

Crear archivos sobrantes

Pros: Personas que usan cosas como node-gyp podría tener archivos de objeto que se generan durante una compilación que nunca debería incluirse en el paquete. Contras: Esto siempre debe ir en el .gitignore de todas formas. Debe colocar estas cosas aquí si usa una .npmignore archivo ya que anula .gitignore desde el punto de vista de npm.

Pruebas

Pros: Menos equipaje en su código de producción. Contras: No se pueden ejecutar pruebas en entornos en vivo en la pequeña posibilidad de que exista una falla específica del sistema, como una versión desactualizada de la ejecución de un nodo que hace que falle una prueba.

Configuraciones de integración continua / Meta archivos

Pros: Nuevamente, menos equipaje. Cosas como .travis.yml no son necesarios para usar, probar o ver el código.

Documentos no readme y ejemplos de código

Pros: Menos equipaje. Algunas personas existen en la escuela de pensamiento en la que si no puede expresar al menos la funcionalidad mínima viable en su archivo 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 Github-páginas

Pros: Ciertamente no necesita ensuciar sus lanzamientos con CNAME archivos o marcador de posición index.htmls si utiliza su módulo sirve servicio doble como una gh-pages repositorio también.

bower.json y amigos

Pros: 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, mantendría esas cosas en el paquete. Cuando hago un npm install, Solo debería confiar en npm y no en otras fuentes externas.


Básicamente, debe usarlo siempre que haya algo que desee mantener fuera de su paquete npm pero no fuera de su repositorio npm. No es una larga lista de elementos, pero npm preferiría construir en la funcionalidad que tener personas atrapadas con objetos irrelevantes en su paquete.


74
2017-08-04 19:13



estoy de acuerdo con la respuesta corta 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 para ser descargado.

Mi contribución a esas respuestas:

.npmignore es el lista negra forma de lograr la selección del archivo del paquete. Pero de una manera más práctica, puedes lista blanca archivos que necesita incluir en su paquete usando el campo de archivos en tu paquete .json:

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

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


46
2018-05-24 18:56



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

Sepa que las personas que instalen su biblioteca solo necesitarán que su biblioteca se ejecute, cualquier otra cosa no será necesaria.

Por ejemplo, cuando alguien instala una biblioteca, es probable que a él / ella no le importe su .travis.yml o tu .jshintrc 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


15
2017-08-04 19:12



No incluya sus pruebas. A menudo, las pruebas son como 5 veces el tamaño de la base de código real. Siempre y cuando tus pruebas sean Github, etc., eso es suficiente.

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

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

¿Cómo probar un resultado `npm publish`, sin publicar realmente en NPM?


0
2018-06-27 22:59