Respuestas:
La respuesta no es tan fácil como sugiere Alberto Zaccagni. Si desarrolla aplicaciones (especialmente aplicaciones empresariales), incluir node_modules en su repositorio de git es una opción viable y la alternativa que elija dependerá de su proyecto.
Debido a que argumentó muy bien contra node_modules, me concentraré en argumentos para ellos.
Imagine que acaba de terminar la aplicación empresarial y tendrá que soportarla durante 3-5 años. Definitivamente no desea depender del módulo npm de alguien que mañana puede desaparecer y ya no puede actualizar su aplicación.
O tiene sus módulos privados a los que no se puede acceder desde Internet y no puede construir su aplicación en Internet. O tal vez no desee depender de su compilación final en el servicio npm por alguna razón.
Puede encontrar pros y contras en este artículo de Addy Osmani (aunque se trata de Bower, es casi la misma situación). Y terminaré con una cita de la página de inicio de Bower y el artículo de Addy:
"Si no está creando un paquete destinado a ser consumido por otros (por ejemplo, si está creando una aplicación web), siempre debe verificar los paquetes instalados en el control de código fuente".
git checkout foo. Si node_modules no están bajo VCS, el cambio de ramas sí git checkout foo ; npm instally lo que sea que requiera su versión actual de NPM para funcionar;)
Los detalles de los módulos se almacenan en packages.json, eso es suficiente. No hay necesidad de registrarse node_modules.
La gente solía almacenar node_modulesen el control de versiones para bloquear las dependencias de los módulos, pero con npm shrinkwrap ya no es necesario.
Otra justificación para este punto, como @ChrisCM escribió en el comentario:
También vale la pena señalar, cualquier módulo que involucre extensiones nativas no funcionará de arquitectura a arquitectura, y necesita ser reconstruido. Proporcionar una justificación concreta para NO incluirlos en el repositorio.
Recomendaría no registrar en node_modules debido a paquetes como PhantomJS y node-sass, por ejemplo, que instalan el binario apropiado para el sistema actual.
Esto significa que si un Dev se ejecuta npm installen Linux y registra node_modules, no funcionará para otro Dev que clone el repositorio en Windows.
Es mejor verificar los tarballs que npm instala descargas y señalarlos npm-shrinkwrap.json. Puede automatizar este proceso usando shrinkpack .
npm install --global shrinkpacktiene entonces la debilidad diferida, al requerir otros paquetes con los cuales instalar los paquetes reducidos? Esto va en contra de los consejos de Addy.
shrinkpackse requiere dependencia para instalar de manera confiable dependencias de compilación. Por lo tanto, la instalación de la herramienta de compilación en sí se convierte en la debilidad del argumento contra el envío de todas las dependencias de compilación al control de versiones.
Este tema es bastante viejo, ya veo. Pero me falta alguna actualización de los argumentos proporcionados aquí debido a la situación cambiada en el ecosistema de npm.
Siempre aconsejaría no poner node_modules bajo control de versiones. Casi todos los beneficios de hacerlo como se enumeran en el contexto de la respuesta aceptada están bastante desactualizados a partir de ahora.
Los paquetes publicados ya no pueden ser revocados del registro npm tan fácilmente. Por lo tanto, no debe temer perder las dependencias en las que su proyecto se ha basado antes.
Poner el archivo package-json.lock en VCS está ayudando con las dependencias que se actualizan con frecuencia, lo que probablemente resulte en diferentes configuraciones aunque dependa del mismo archivo package.json.
Por lo tanto, poner node_modules en VCS en caso de tener herramientas de compilación sin conexión podría considerarse el único caso de uso elegible que queda. Sin embargo, node_modules generalmente crece bastante rápido. Cualquier actualización cambiará muchos archivos. Y esto está afectando a los repositorios de diferentes maneras. Si realmente considera los efectos a largo plazo, eso también podría ser un impedimento.
Los VCS centralizados como svn requieren transferir archivos confirmados y desprotegidos a través de la red, lo que va a ser lento cuando se trata de retirar o actualizar una carpeta node_modules.
Cuando se trata de git, esta gran cantidad de archivos adicionales contaminarán instantáneamente el repositorio. Tenga en cuenta que git no rastrea las diferencias entre las versiones de cualquier archivo, sino que almacena copias de cualquiera de las versiones de un archivo tan pronto como un solo carácter ha cambiado. Cada actualización de cualquier dependencia dará como resultado otro gran conjunto de cambios. Su repositorio git crecerá rápidamente debido a que esto afecta las copias de seguridad y la sincronización remota. Si decide eliminar node_modules del repositorio de git más adelante, seguirá siendo parte de él por razones históricas. Si ha distribuido su repositorio git a algún servidor remoto (por ejemplo, para copias de seguridad), limpiarlo es otra tarea dolorosa y propensa a errores en la que se encontrará.
Por lo tanto, si le interesan los procesos eficientes y le gusta mantener las cosas "pequeñas", prefiero usar un repositorio de artefactos por separado, como el Repositorio Nexos (o simplemente un servidor HTTP con archivos ZIP) que proporciona un conjunto de dependencias previamente descargadas para descargar.
No realizar un seguimiento node_modulescon el control de código fuente es la opción correcta porque algunos módulos de NodeJS, como el controlador MongoDB NodeJS, usan complementos NodeJS C ++. Estos complementos se compilan al ejecutar el npm installcomando. Entonces, cuando rastrea el node_modulesdirectorio, puede confirmar accidentalmente un archivo binario específico del sistema operativo.
Estoy de acuerdo con ivoszz en que a veces es útil verificar la carpeta node_modules, pero ...
escenario 1:
Un escenario: utiliza un paquete que se elimina de npm. Si tiene todos los módulos en la carpeta node_modules, entonces no será un problema para usted. Si solo tiene el nombre del paquete en package.json, ya no podrá obtenerlo. Si un paquete tiene menos de 24 horas, puede eliminarlo fácilmente de npm. Si tiene más de 24 horas, debe contactarlos. Pero:
Si se pone en contacto con el servicio de asistencia, comprobarán si eliminar esa versión de su paquete interrumpiría cualquier otra instalación. Si es así, no lo eliminaremos.
Entonces, las posibilidades de esto son bajas, pero hay un escenario 2 ...
escenario 2:
Otro escenario en el que este es el caso: desarrolla una versión empresarial de su software o un software muy importante y escribe en su paquete.json:
"dependencies": {
"studpid-package": "~1.0.1"
}Usas el método function1(x)de ese paquete.
Ahora los desarrolladores de studpid-paquete de cambiar el nombre del método function1(x)a function2(x)y hacen un fallo ... Cambian la versión de su paquete de 1.0.1a 1.1.0. Eso es un problema porque cuando llames npm installla próxima vez, aceptarás la versión 1.1.0porque usaste tilde ( "studpid-package": "~1.0.1").
Llamar function1(x)puede causar errores y problemas ahora.
Pero:
Insertar toda la carpeta node_modules (a menudo más de 100 MB) en su repositorio le costará espacio de memoria. Unos pocos kb (solo package.json) en comparación con cientos de MB (package.json & node_modules) ... Piénselo.
Usted podría hacerlo / debería pensar en ello si:
El software es muy importante.
le cuesta dinero cuando algo falla.
no confías en el registro npm. npm está centralizado y, en teoría, podría cerrarse.
No necesita publicar la carpeta node_modules en el 99.9% de los casos si:
Usted desarrolla un software solo para usted.
has programado algo y solo quieres publicar el resultado en GitHub porque alguien más podría estar interesado en él.
Si no desea que node_modules esté en su repositorio, simplemente cree un .gitignorearchivo y agregue la línea node_modules.
npm installa Windows y MacOS podría generar diferentes archivos (archivos dependientes del sistema operativo) en algunos paquetes. Pero no estoy seguro de eso. ¿Alguien puede verificar que esto es cierto?
package-lock.json. Si hay un problema en el futuro con una actualización de studpid-package, puede revertir el archivo de bloqueo para averiguar la versión exacta que funcionó para usted.
Me gustaría ofrecer una alternativa a la mitad del camino.
node_modulesa git.package-lock.jsonarchivo para concretar sus versiones de dependencia.En el raro caso de que no pueda acceder a NPM (u otros registros que use) o un paquete específico en NPM, tiene una copia de node_modules y puede continuar trabajando hasta que restaure el acceso.
Una cosa más a tener en cuenta: el registro node_moduleshace que sea más difícil / imposible utilizar la diferencia entre dependenciesy devDependencies.
Sin embargo, por otro lado, se podría decir que es tranquilizador impulsar a la producción exactamente el mismo código que pasó por las pruebas, por lo que se incluye devDependencies.
No se requiere que check_modules se registren si las dependencias se mencionan en package.json. Cualquier otro programador puede simplemente obtenerlo haciendo npm install y npm es lo suficientemente inteligente como para hacer que node_modules en su directorio de trabajo para el proyecto.