¿Debo enviar el archivo package-lock.json creado por npm 5?

Resuelto rink.attendant.6 asked hace 7 años • 14 respuestas

npm 5 se lanzó hoy y una de las nuevas características incluye instalaciones deterministas con la creación de un package-lock.jsonarchivo.

¿Se supone que este archivo debe mantenerse en control de código fuente?

Supongo que es similar a yarn.locky composer.lock, y se supone que ambos deben mantenerse en control de fuente.

rink.attendant.6 avatar May 27 '17 00:05 rink.attendant.6
Aceptado

Sí, package-lock.jsonestá destinado a ser registrado en el control de fuente. Si está utilizando npm 5+, es posible que vea este aviso en la línea de comando: created a lockfile as package-lock.json. You should commit this file.Según npm help package-lock.json:

package-lock.jsonse genera automáticamente para cualquier operación en la que npm modifique el node_modulesárbol o package.json. Describe el árbol exacto que se generó, de modo que las instalaciones posteriores puedan generar árboles idénticos, independientemente de las actualizaciones de dependencia intermedias.

Este archivo está destinado a guardarse en repositorios de origen y sirve para varios propósitos:

  • Describa una representación única de un árbol de dependencias de modo que se garantice que los compañeros de equipo, las implementaciones y la integración continua instalen exactamente las mismas dependencias.

  • Proporcionar una posibilidad para que los usuarios "viajen en el tiempo" a estados anteriores node_modulessin tener que confirmar el directorio.

  • Para facilitar una mayor visibilidad de los cambios del árbol a través de diferencias de control de fuente legibles.

  • Y optimice el proceso de instalación permitiendo que npm omita resoluciones repetidas de metadatos para paquetes instalados previamente.

Un detalle clave package-lock.jsones que no se puede publicar y se ignorará si se encuentra en cualquier lugar que no sea el paquete de nivel superior. Comparte formato con npm-shrinkwrap.json, que es esencialmente el mismo archivo, pero permite la publicación. Esto no se recomienda a menos que implemente una herramienta CLI o utilice el proceso de publicación para producir paquetes de producción.

Si ambos package-lock.jsony npm-shrinkwrap.jsonestán presentes en la raíz de un paquete, package-lock.jsonse ignorarán por completo.

vine77 avatar May 26 '2017 22:05 vine77

Si deberías:

  1. cometer el package-lock.json.
  2. úselo npm cien lugar denpm install cuando cree sus aplicaciones tanto en su CI como en su máquina de desarrollo local

El npm ciflujo de trabajo requiere la existencia de un archivo package-lock.json.

Una gran desventaja del npm installcomando es su comportamiento inesperado que puede mutar package-lock.json, mientras que npm cisolo usa las versiones especificadas en el archivo de bloqueo y produce un error.

  • si package-lock.jsony package.jsonno están sincronizados
  • si package-lock.jsonfalta a.

Por lo tanto, ejecutar npm installlocalmente, especialmente. en equipos más grandes con varios desarrolladores, puede generar muchos conflictos dentro del programa package-lock.jsony que los desarrolladores decidan eliminarlo por completo package-lock.json.

Sin embargo, existe un fuerte caso de uso para poder confiar en que las dependencias del proyecto se resuelven repetidamente de manera confiable en diferentes máquinas.

De a package-lock.jsonse obtiene exactamente eso: un estado de funcionamiento conocido.

En el pasado, tenía proyectos sin archivos // package-lock.jsoncuya compilación fallaría algún día porque una dependencia aleatoria recibió una actualización importante.npm-shrinkwrap.jsonyarn.lock

Estos problemas son difíciles de resolver ya que a veces hay que adivinar cuál fue la última versión funcional.

Si desea agregar una nueva dependencia, aún debe ejecutar npm install {dependency}. Si desea actualizar, utilice npm update {dependency}o npm install ${dependendency}@{version}y confirme el archivo package-lock.json.

Si falla una actualización, puede volver al último archivo funcional conocido package-lock.json.

Para citar npm doc :

Se recomienda encarecidamente que envíe el bloqueo del paquete generado al control de código fuente: esto permitirá que cualquier otra persona de su equipo, sus implementaciones, su CI/integración continua y cualquier otra persona que ejecute npm install en el código fuente de su paquete obtenga exactamente el mismo árbol de dependencia. que estabas desarrollando. Además, las diferencias de estos cambios son legibles por humanos y le informarán de cualquier cambio que npm haya realizado en sus node_modules, para que pueda notar si se actualizó, elevó, etc. alguna dependencia transitiva.

Y con respecto a la diferencia entre npm civsnpm install :

  • El proyecto debe tener un package-lock.json o npm-shrinkwrap.json existente.
  • Si las dependencias en el bloqueo del paquete no coinciden con las de package.json, npm cise cerrará con un error, en lugar de actualizar el bloqueo del paquete.
  • npm ciSolo puede instalar proyectos completos a la vez: no se pueden agregar dependencias individuales con este comando.
  • Si node_modulesya está presente, se eliminará automáticamente antes de que npm cicomience su instalación.
  • Nunca escribirá en package.jsonninguno de los paquetes bloqueados: las instalaciones están esencialmente congeladas.

Nota: publiqué una respuesta similar aquí.

k0pernikus avatar May 22 '2019 10:05 k0pernikus

Sí, está destinado a ser registrado. Quiero sugerir que obtenga su propio compromiso único. Descubrimos que agrega mucho ruido a nuestros diferenciales.

xer0x avatar Jun 16 '2017 21:06 xer0x

Sí, la mejor práctica es realizar el check-in (SÍ, CHECK-IN)

Estoy de acuerdo en que causará mucho ruido o conflicto al ver la diferencia. Pero los beneficios son:

  1. Garantice exactamente la misma versión de cada paquete entre sus entornos de desarrollo y producción . Esta parte es la más importante cuando se construye en diferentes entornos en diferentes momentos. Puede usarlo ^1.2.3en su package.json, pero ¿cómo puede asegurarse de que cada vez npm installelija la misma versión en su máquina de desarrollo y en el servidor de compilación, especialmente aquellos paquetes de dependencia indirecta? Bueno, package-lock.jsonme aseguraré de eso. (Con la ayuda del npm cicual se instalan paquetes basados ​​en el archivo de bloqueo)
  2. Mejora el proceso de instalación.
  3. Ayuda con la nueva función de auditoría npm audit fix.
Xin avatar Jun 15 '2018 03:06 Xin

No comprometo este archivo en mis proyectos. Cuál es el punto de ?

  1. se genera
  2. Es la causa de un error de integridad del código SHA1 en gitlab con compilaciones gitlab-ci.yml

Aunque es cierto que nunca uso ^ en mi paquete.json para bibliotecas porque tuve malas experiencias con él.

[EDITAR] Esta respuesta está desactualizada (2018) y, para ser justos, también carece de conocimiento. A partir de abril de 2023, mi respuesta sería => POR SUPUESTO, DEBE COMPROMETER ESTE ARCHIVO : por ejemplo, el comando de instalación estándar en plataformas CI necesitaría npm cique ese archivo funcione correctamente para ASEGURAR que el árbol de dependencias sea exactamente el mismo que el confirmado;

Deunz avatar Jul 12 '2018 14:07 Deunz