¿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 control de código fuente?

Supongo que es similar a yarn.locky composer.lock, los cuales se supone que se mantienen en control de fuente.

Sí, package-lock.jsonestá diseñado para registrarse 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.De acuerdo con 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 enviado a repositorios de origen y tiene 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 garantizadas para instalar exactamente las mismas dependencias.

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

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

• Y optimice el proceso de instalación permitiendo que npm omita resoluciones de metadatos repetidas 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 un 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 use 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.

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

Si deberías:

1. cometer el package-lock.json.
2. utilícelo en npm cilugar denpm install al crear sus aplicaciones tanto en su CI como en su máquina de desarrollo local

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

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

• si package-lock.jsony no package.jsonestán sincronizados
• si package-lock.jsonfalta un.

Por lo tanto, ejecutar npm installlocalmente, esp. en equipos más grandes con varios desarrolladores, puede dar lugar a muchos conflictos dentro del package-lock.jsony los desarrolladores pueden decidir eliminar por completo el package-lock.json.

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

De un package-lock.jsonobtienes exactamente eso: un estado conocido para trabajar.

En el pasado, tenía proyectos sin package-lock.json/ npm-shrinkwrap.json/ yarn.lockarchivos cuya compilación fallaría algún día porque una dependencia aleatoria obtuvo 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 que funciona.

Si desea agregar una nueva dependencia, aún ejecuta npm install {dependency}. Si desea actualizar, use npm update {dependency}o npm install ${dependendency}@{version}y confirme el archivo 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 la 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 la fuente de su paquete obtenga exactamente el mismo árbol de dependencias en el que te 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 alguna dependencia transitiva se actualizó, elevó, etc.

Y en lo que respecta 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, se npm cicerrará 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 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í

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. Garantiza 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.3en su package.json, pero ¿cómo puede asegurarse de que cada vez npm installrecogerá la misma versión en su máquina de desarrollo y en el servidor de compilación, especialmente esos paquetes de dependencia indirecta? Bueno, package-lock.jsoneso se asegurará. (Con la ayuda del npm cicual 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 la versión 6 de npm).

No envío 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 gitlab-ci.yml builds

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

A 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 yb / package-lock.json difieren cada vez que se cambia el archivo de bloqueo del paquete. Además, algunos servicios de Git (en particular, GitLab, pero no GitHub) también excluirán estos archivos (¡no se cambiaron más 10k líneas!) de las diferencias cuando se visualizan en línea al hacer esto.

Sí, puede enviar este archivo. De los documentos oficiales de la 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 enviado a repositorios de origen [.]

Deshabilitar package-lock.json globalmente

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 confirmar package-lock.json

La razón principal para confirmar 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 las versiones principales automáticamente para evitar cambios incompatibles con versiones anteriores en paquetes de terceros, la confirmación de bloqueo de 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 toman el impulso de sus cambios.

Contras:-

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

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

Mi uso de npm es generar css / js minificado / 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 css. Si package-lock.json tiene algún control predominante sobre lo que hay en package.json, entonces puede ser necesario que haya una versión de este archivo. En mi experiencia, o bien 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 installse ejecuta en el servidor, cambia package-lock.json, y si hay cambios en un archivo que está registrado por el repositorio en el servidor, la siguiente implementación NO le permitirá extraer nuevos cambios desde el origen. Es decir, no puede implementar porque la extracción sobrescribirá los cambios que se han realizado en package-lock.json.

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

Si me falta algo, corríjame en los comentarios, pero el hecho de que el control de versiones se toma 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 compilar paquetes cuando se produce la instalación de npm, ya que cuando lo elimino, npm install se queja de la siguiente manera:

[email protected]:introcart_wagtail$ rm package.json
[email protected]: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

[email protected]:introcart_wagtail$ rm package-lock.json 
[email protected]: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 ...

Todas las respuestas dicen "SÍ" pero eso también depende del proyecto, el doc 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.jsondependencia, pero debe usarla package-lock.jsonen su repositorio para bloquear la versión de su dependencia de prueba, construir dependencias ...

Sin embargo, si está utilizando lerna para administrar proyectos con varios paquetes, debe colocar el package.jsonúnico en la raíz de su repositorio, no en cada subpaquete con el que se crea npm init. Obtendrás algo como eso:

.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