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

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 el control de origen?

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

Sí, package-lock.jsonestá destinado a ser verificado en el control de fuente. Si está usando npm 5, puede ver esto 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 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 node_modulessin tener que comprometer 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 package-lock.jsones 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 ambos package-lock.jsony npm-shrinkwrap.jsonestán presentes en la raíz de un paquete, package-lock.jsonserán completamente ignorados.

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

Si deberías:

1. cometer el package-lock.json.
2. use en npm cilugar denpm install cuando crea sus aplicaciones tanto en su CI como en su máquina de desarrollo local

El npm ciflujo de trabajo requiere la existencia de a 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 el package-lock.jsony no package.jsonestán sincronizados
• si package-lock.jsonfalta un

Por lo tanto, ejecutándose npm installlocalmente, esp. en equipos más grandes con múltiples desarrolladores, puede generar muchos conflictos dentro de los package-lock.jsondesarrolladores y decidir eliminarlos 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.jsonobtienes exactamente eso: un estado conocido de trabajo.

En el pasado, tenía proyectos sin archivos package-lock.json/ npm-shrinkwrap.json/ yarn.lockcuya 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 cualquiera npm update {dependency}o npm install ${dependendency}@{version}y confirme el cambio package-lock.json.

Si falla una actualización, puede volver al último trabajo conocido 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 de cualquier cambio que npm haya realizado en sus node_modules, para que pueda notar si alguna dependencia transitiva se actualizó, izó, etc.

Y en lo que respecta a la diferencia entre npm civsnpm 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 cisaldrá 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 node_modulesya está presente, se eliminará automáticamente antes de npm cicomenzar su instalación.
• Nunca escribirá en package.jsonninguno de los paquetes bloqueados: las instalaciones están esencialmente congeladas.

Nota: publiqué una respuesta similar aquí

Sí, la mejor práctica es hacer 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. 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 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 esos paquetes de dependencia indirectos? Bueno, package-lock.jsonse asegurará de eso. (Con la ayuda de npm cique instala 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(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. Es generado
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 package.json para libs porque tuve malas experiencias con él.

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 10k líneas!) desde los diferenciales cuando se visualizan en línea al hacer esto.

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

package-lock.jsonse genera automáticamente para cualquier operación en la que se npmmodifique el node_modulesárbol 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í, 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: -

• 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, la confirmación de paquetes de bloqueo 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 toman el tirón de sus cambios.

Contras:-

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

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

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 superior 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 despliegue 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 npm installse ejecuta en el servidor, cambia package-lock.json, y si hay cambios en un archivo que el repositorio registra en el servidor, el próximo 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

> 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 ...