¿Qué debería hacer con el directory node_modules de Grunt cuando publico mi proyecto en GitHub?

Este es mi primer proyecto usando Grunt y Git. En mi proyecto, tengo el directory ' * node_modules * ' que creé con el command ' npm install grunt '. Ahora quiero publicar mi proyecto en GitHub.

¿Debería mi proyecto contener 'node_modules' o debería omitirlo? Me temo que hace que el proyecto sea aterrador para los desarrolladores que no están familiarizados con Grunt. De hecho, estoy desconcertado por qué debe instalar el ronco para cada proyecto por separado. ¿Por qué no es posible instalarlo globalmente?

Aquí está mi installation: grunt-contrib-concat, grunt-contrib-jshint, grunt-contrib-qunit, grunt-contrib-uglify, grunt-contrib-watch.

La razón por la que no debe instalar los plugins grunt y grunt en todo el mundo es porque solo podría tener una versión de cada uno instalada a la vez. Al trabajar con un equipo, también significa que cada miembro de su equipo debe ejecutar la misma versión de grunt y cada plugin grunt.

Coordinar estas versiones con un equipo y cambiar las versiones a medida que saltas a diferentes proyectos es una pesadilla. La solución, instala todo localmente. Es solo espacio de files y la mayoría de los modules no ocupan mucho espacio.

La mayoría de las personas no asigna su carpeta node_modules a github. Cada dependencia enumerada en su package.json se puede instalar nuevamente escribiendo: npm install en la misma carpeta.

Use npm install grunt --save-dev para savelo en su package.json mientras instala plugins y modules.

La única razón sensata para confirmar node_modules , IMO, es con una aplicación privada y un repository destinado a ser desplegado en la producción. Donde quiera asegurarse de que sus dependencies estén bloqueadas y no rompan algo al presionar. Todavía hay otras estrategias para evitar la node_modules , incluso con este caso de uso (como npm shrinkwrap).

En breve:

  • Si está implementando una aplicación y está paranoico de bloquear sus dispositivos, confíe sus node_modules .
  • Todo lo demás, no confíes tus node_modules .

@ "La única razón sensata para confirmar node_modules, IMO, es con una aplicación privada y un repository destinado a ser desplegado en la producción".

Empecé sin comprometer nunca mis node_modules en el repository y solo realizo cambios en package.json. Pero resultó que era una muy mala idea para un proyecto con múltiples desarrolladores y un puñado de twigs de características experimentales. Como la carpeta node_module no está versionada con git, terminará necesitando ejecutar npm install en cada switch de twig, porque los modules pueden diferir entre versiones. Una verdadera pesadilla …

Usted terminará escuchando "¡Esta mierda no funciona otra vez!", Solo porque uno había actualizado un module de nodo en una twig de características. Así que ahora recomiendo include node_modules para proyectos con múltiples desarrolladores y sucursales. Quita mucho dolor …

Editar: Solo quiero añadir algunas otras cosas a tener en count con el check-in / no marcado en modules de nodos que tuve que (dolorosamente) aprender:

  1. Siempre bloquee sus versiones en package.json, lo que significa básicamente eliminar todos los modificadores frente a los numbers de versión de sus packages (como: ~,>, * y lo que sea posible). Si alguien ejecuta la installation de npm, quiere que se lleven EXACTAMENTE lo que tiene (La versión semántica en teoría es genial y todo, pero lo siento, no es confiable, y nunca / nunca quiere que los packages se actualicen sin su conocimiento). De lo contrario, simplemente mira el mundo quemar una y otra vez …
  2. Si trabaja en un entorno mixto de SO, hay algunos packages de grunt problemáticos que solo deben revisarse con precaución, por ejemplo grunt-imagemin, lo que puede dificultar las comprobaciones en Windows, usando msysgit porque sus routes son demasiado largas. Nombre de file demasiado largo en git para windows
  3. Descubrí que es una buena práctica para mí poner mi automation de flujo de trabajo y el package acorde npm en su propia subcarpeta / repository para reutilización y mejor mantenimiento del proyecto, porque evita que los modules de automation se mezclen con los packages de aplicación nodej reales.