node.js - warning - whats package lock json

¿Confirmo el archivo package-lock.json creado por npm 5? (10)

Mi uso de npm es generar css / js minified / uglified 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 realizar llamadas ajax, trabajar dentro de un marco VUE y / o trabajar con el CSS. Si package-lock.json tiene un control primordial sobre lo que está en package.json, entonces puede ser necesario que haya una versión de este archivo. En mi experiencia, no afecta lo que instala npm install, o si lo hace, hasta la fecha no ha afectado negativamente las aplicaciones que implemento a mi conocimiento. No uso mongodb u otras aplicaciones 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 nodo y npm se realiza manualmente en cada servidor, pero tengo cuidado de que sean iguales.

Cuando se ejecuta npm install en el servidor, cambia package-lock.json, y si hay cambios en un archivo que el repositorio registra en el servidor, el siguiente despliegue WONT le permitirá extraer nuevos cambios desde el origen. Es decir, no se puede implementar porque la extracción sobrescribirá los cambios que se han realizado en package-lock.json.

Ni siquiera puede sobrescribir un paquete-lock.json generado localmente con lo que está en el repositorio (restablecer el maestro de origen duro), ya que npm se quejará cuando emita un comando si el paquete-lock.json no refleja lo que está en node_modules debido a la instalación de npm, rompiendo así la implementación. Ahora, 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), se debe ignorar package-lock.json.

Si me falta algo, corríjame en los comentarios, pero el punto de que se toma la versión 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 construir 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 > [email protected] dev /home/jason/webapps/introcart_devtools/introcart_wagtail > NODE_ENV=development webpack --progress --colors --watch --mode=development 10% building 0/1 modules 1 active ...

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

¿Se supone que este archivo debe mantenerse en el control de origen?

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

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

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

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

Saludos.

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 modifica el archivo de bloqueo del paquete. Además, algunos servicios de Git (especialmente GitLab, pero no GitHub) también excluirán estos archivos (¡no se han cambiado más de 10 mil líneas!) desde los diferenciales cuando se visualizan en línea al hacer esto.

Sí, package-lock.json está destinado a ser verificado en el control de código fuente. Si está utilizando npm 5, puede ver esto en la línea de comando: created a lockfile as package-lock.json. You should commit this file. created a lockfile as package-lock.json. You should commit this file. De acuerdo con 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 pueden generar árboles idénticos, independientemente de las actualizaciones de dependencia intermedias.

Este archivo está destinado a ser confirmado 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.

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 de árbol a través de diferencias de control de fuente legible.

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

Un detalle clave sobre package-lock.json es que no se puede publicar, y se ignorará si se encuentra en otro lugar que no sea el paquete de nivel superior. Comparte un formato con npm-shrinkwrap.json (5), 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 tanto package-lock.json como npm-shrinkwrap.json están presentes en la raíz de un paquete, package-lock.json se ignorará por completo.

Sí, debe confirmar el package-lock.json .

También recomiendo usar npm ci lugar de npm install al npm install sus aplicaciones tanto en su CI como en su máquina de desarrollo local y ese flujo de trabajo requiere la existencia de un package-lock.json .

Una gran desventaja del comando npm install es 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 están sincronizados.

Por lo tanto, ejecutando npm install localmente, especialmente. en equipos más grandes con múltiples desarrolladores, puede generar muchos conflictos dentro del package-lock.json y los desarrolladores deciden eliminar completamente el 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 un package-lock.json obtienes exactamente eso: un estado conocido para trabajar.

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

Esos problemas son difíciles de resolver ya que a veces tienes que adivinar cuál fue la última versión de trabajo.

Si desea agregar una nueva dependencia, aún ejecuta npm install {dependency} . Si desea actualizar, use npm update {dependency} y package-lock.json modificado package-lock.json . (Si falla una actualización, puede volver al último package-lock.json trabajo package-lock.json ).

Para citar npm doc :

Se recomienda encarecidamente que confirme el bloqueo del paquete generado al control de origen: esto permitirá que cualquier otra persona en su equipo, sus implementaciones, su CI / integración continua y cualquier otra persona que ejecute npm install en su fuente de paquete para obtener exactamente el mismo árbol de dependencias que estabas desarrollando Además, los diferenciales 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ó, se izó, etc.

Y en lo que respecta a la diferencia entre npm ci vs npm install :

El proyecto debe tener un paquete-lock.json o npm-shrinkwrap.json existentes.

Si las dependencias en el bloqueo del paquete no coinciden con las del paquete.json, npm ci saldrá con un error, en lugar de actualizar el bloqueo del paquete.

npm ci solo puede instalar proyectos completos a la vez: las dependencias individuales no se pueden agregar con este comando.

Si un node_modules ya está presente, se eliminará automáticamente antes de que npm ci comience su instalación.

Nunca escribirá en package.json ni en ninguno de los bloqueos de paquetes: las instalaciones están esencialmente congeladas.

Nota: publiqué una respuesta similar here

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

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

Pros: -

Todos en el proyecto estarán en la misma versión del paquete, todo lo que tienes que hacer es

npm install
Si sigue un control de versiones estricto y no permite la actualización automática a las versiones principales para evitar cambios incompatibles con versiones anteriores en paquetes de terceros, la confirmación del bloqueo de paquetes ayuda mucho.

Contras:-

Puede hacer que tus solicitudes de extracción se vean feas :) ''

Sí, está destinado a ser registrado. Quiero sugerir que obtenga su propia confirmación única. Descubrimos que agrega mucho ruido a nuestras diferencias.

Sí, puedes 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 pueden generar árboles idénticos, independientemente de las actualizaciones de dependencia intermedias.

Este archivo está destinado a ser confirmado en repositorios de origen [.]

Deshabilitar globalmente package-lock.json

escriba lo siguiente en su terminal:

npm config set package-lock false

esto realmente funciona para mí como magia

Sí, la mejor práctica es registrarse

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

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 que npm install elija la misma versión en su máquina de desarrollo y en el servidor de compilación, especialmente esos paquetes de dependencia indirectos? Bueno, package-lock.json se asegurará de eso. (Con la ayuda de npm ci que instala paquetes basados en el archivo de bloqueo)
Mejora el proceso de instalación.
ayuda con la nueva función de auditoría npm audit fix (creo que la función de auditoría es de npm versión 6).