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

Sí, package-lock.json está diseñado para incorporarse al control de código fuente. Si usa 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.json se genera automáticamente para cualquier operación en la que npm modifique el árbol node_modules 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 ser enviado a los repositorios de origen y sirve para varios propósitos:

• Describa una única representación de un árbol de dependencias de modo que los compañeros de equipo, las implementaciones y la integración continua estén garantizados para instalar exactamente las mismas dependencias.

• Proporcione una facilidad para que los usuarios "viajen en el tiempo" a estados anteriores de node_modules sin tener que confirmar el directorio en sí.

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

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

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

Si tanto package-lock.json como npm-shrinkwrap.json están presentes en la raíz de un paquete, se ignorará por completo package-lock.json .

Enviar package-lock.json al control de versiones del código fuente significa que el proyecto usará una versión específica de las dependencias que pueden o no coincidir con las definidas en package.json. mientras que la dependencia tiene una versión específica sin Caret (^) y Tilde (~) como puede ver, eso significa que la dependencia no se actualizará a la versión más reciente. y npm install tomará la misma versión y la necesitamos para nuestra versión actual de Angular.

Nota: se recomienda encarecidamente que se confirme package-lock.json SI agregué cualquier Caret (^) y Tilde (~) a la dependencia para que se actualice durante el CI.

Sí, es una práctica estándar confirmar package-lock.json .

La razón principal para package-lock.json es que todos en el proyecto tienen la misma versión del paquete.

Ventajas:

• Si sigue un control de versiones estricto y no permite la actualización a versiones principales automáticamente para evitar cambios incompatibles con versiones anteriores en paquetes de terceros, comprometer el bloqueo del paquete ayuda mucho.
• Si actualiza un paquete en particular, se actualiza en package-lock.json y todos los que usan el repositorio se actualizan a esa versión en particular cuando reciben sus cambios.

Contras:

• Puede hacer que sus solicitudes de extracción se vean feas :)

npm install no se asegurará de que todos en el proyecto estén en la misma versión del paquete. npm ci ayudará con esto.

Si deberías:

1. confirme el package-lock.json .
2. use npm ci en lugar de npm install al crear sus aplicaciones tanto en su CI como en su máquina de desarrollo local

El flujo de trabajo npm ci requiere la existencia de un package-lock.json .

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

• si el package-lock.json y el package.json no están sincronizados
• si falta un package-lock.json .

Por lo tanto, ejecutar npm install localmente, esp. en equipos más grandes con múltiples desarrolladores, puede generar muchos conflictos dentro de package-lock.json y los desarrolladores pueden decidir eliminar completamente el package-lock.json en su lugar.

Sin embargo, existe un caso de uso sólido para poder confiar en que las dependencias del proyecto se resuelven de manera repetible y confiable en diferentes máquinas.

De un package-lock.json obtienes exactamente eso: un estado que se sabe que funciona.

En el pasado, tenía proyectos sin package-lock.json / npm-shrinkwrap.json / yarn.lock cuya compilación fallaría un día porque una dependencia aleatoria recibió una actualización de última hora.

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

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

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

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 dependencias. que estabas desarrollando. Además, las diferencias de estos cambios son legibles por humanos y le informarán sobre cualquier cambio que npm haya realizado en sus node_modules, para que pueda notar si alguna dependencia transitiva se actualizó, elevó, etc.

Y con respecto a la diferencia entre npm ci vs npm install :

• El proyecto debe tener un paquete-lock.json o npm-shrinkwrap.json existente.
• Si las dependencias en el bloqueo del paquete no coinciden con las de package.json, npm ci se cerrará con un error, en lugar de actualizar el bloqueo del paquete.
• npm ci solo puede instalar proyectos completos a la vez: no se pueden agregar dependencias individuales con este comando.
• Si un node_modules ya está presente, se eliminará automáticamente antes npm ci comience su instalación.
• Nunca escribirá en package.json ni en ninguno de los bloqueos de paquete: las instalaciones están esencialmente congeladas.

Nota: publiqué una respuesta similar aquí

Todas las respuestas dicen "SÍ", pero eso también depende del proyecto, el documento dice:

Un detalle clave sobre package-lock.json es que no se puede publicar y se ignorará si se encuentra en cualquier lugar que no sea el paquete de nivel superior.

Esto significa que no necesita publicar en npm su package-lock.json para la dependencia, pero necesita usar package-lock.json en su repositorio para bloquear la versión de su dependencia de prueba, construir dependencias...

Sin embargo, si está utilizando lerna para administrar proyectos con múltiples paquetes, debe colocar el package.json solo en la raíz de su repositorio, no en cada subpaquete creado con npm init . Obtendrás algo así:

 .git lerna.json package.json package-lock.json <--- here packages/a/package.json packages/a/lib/index.js packages/b/package.json packages/b/lib/index.js

Para las personas que se quejan del ruido al hacer git diff:

 git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Lo que hice fue usar un alias:

 alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Para ignorar package-lock.json en diffs para todo el repositorio (todos los que lo usan), puede agregar esto a .gitattributes :

 package-lock.json binary yarn.lock binary

Esto dará como resultado diferencias que muestran "Los archivos binarios a/package-lock.json y b/package-lock.json difieren cada vez que se cambió el archivo de bloqueo del paquete. Además, algunos servicios de Git (especialmente GitLab, pero no GitHub) también excluirán estos archivos (¡no más 10k líneas cambiadas!) de las diferencias cuando se ven en línea al hacer esto.

Sí, la mejor práctica es registrarse (SÍ, CHECK-IN)

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

1. garantizar exactamente la misma versión de cada paquete . Esta parte es la más importante cuando se construye en diferentes entornos en diferentes momentos. Puede usar ^1.2.3 en su package.json , pero ¿cómo puede asegurarse de que cada vez npm install seleccione la misma versión en su máquina de desarrollo y en el servidor de compilación, especialmente en los paquetes de dependencia indirecta? Bueno, package-lock.json se asegurará de eso. (Con la ayuda de npm ci que instala paquetes basados en el archivo de bloqueo)
2. mejora el proceso de instalación.
3. ayuda con la nueva función npm audit fix (creo que la función de auditoría es de npm versión 6).

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

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

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

Deshabilite package-lock.json globalmente

escribe lo siguiente en tu terminal:

 npm config set package-lock false

esto realmente funciona para mí como magia

Mi uso de npm es generar css/js minimizado/uglificado y generar el javascript necesario en las páginas servidas por una aplicación django. En mis aplicaciones, Javascript se ejecuta en la página para crear animaciones, algunas veces realiza llamadas ajax, trabaja dentro de un marco VUE y/o trabaja con css. Si package-lock.json tiene algún control primordial sobre el contenido de package.json, entonces puede ser necesario que haya una versión de este archivo. Según mi experiencia, no afecta lo que instala npm install o, si lo hace, hasta la fecha no ha afectado negativamente a las aplicaciones que implemento, que yo sepa. No uso mongodb u otras aplicaciones similares que tradicionalmente son clientes ligeros.

Elimino package-lock.json del repositorio porque npm install genera este archivo, y npm install es parte del proceso de implementación en cada servidor que ejecuta la aplicación. El control de versiones de node y npm se realiza manualmente en cada servidor, pero tengo cuidado de que sean iguales.

Cuando npm install se ejecuta en el servidor, cambia package-lock.json, y si hay cambios en un archivo registrado por el repositorio en el servidor, la próxima implementación NO le permitirá obtener nuevos cambios desde el origen. Es decir, no puede implementar porque la extracción sobrescribirá los cambios realizados en package-lock.json.

Ni siquiera puede sobrescribir un paquete-lock.json generado localmente con lo que está en el repositorio (restablecer maestro de origen duro), ya que npm se quejará cada vez que emita un comando si el paquete-lock.json no refleja lo que está en node_modules debido a la instalación de npm, lo que interrumpe la implementación. Ahora bien, si esto indica que se han instalado versiones ligeramente diferentes en node_modules, una vez más, eso nunca me ha causado problemas.

Si node_modules no está en su repositorio (y no debería estarlo), entonces se debe ignorar package-lock.json.

Si me estoy perdiendo algo, corríjame en los comentarios, pero el hecho de que la versión se haya tomado de este archivo no tiene sentido. El archivo package.json tiene números de versión, y supongo que este archivo es el que se usa para crear paquetes cuando se produce la instalación de npm, ya que cuando lo elimino, la instalación de npm se queja de la siguiente manera:

 jason@localhost:introcart_wagtail$ rm package.json jason@localhost:introcart_wagtail$ npm install npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

y la compilación falla, sin embargo, al instalar node_modules o aplicar npm para compilar js/css, no se presenta ninguna queja si elimino package-lock.json

 jason@localhost:introcart_wagtail$ rm package-lock.json jason@localhost:introcart_wagtail$ npm run dev > introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail > NODE_ENV=development webpack --progress --colors --watch --mode=development 10% building 0/1 modules 1 active ...

Sí, puede confirmar este archivo. De los documentos oficiales de npm :

package-lock.json se genera automáticamente para cualquier operación en la que npm modifique el árbol node_modules 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 ser enviado a repositorios de origen[.]