npm 5 se lanzó hoy y una de las nuevas funciones incluye instalaciones deterministas con la creación de un archivo package-lock.json
.
¿Se supone que este archivo debe mantenerse en control de fuente?
Supongo que es similar a yarn.lock
y composer.lock
, los cuales se supone que deben mantenerse en control de fuente.
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 árbolnode_modules
opackage.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
comonpm-shrinkwrap.json
están presentes en la raíz de un paquete, se ignorará por completopackage-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:
Contras:
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:
package-lock.json
.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.
package-lock.json
y el package.json
no están sincronizadospackage-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 antesnpm 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.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)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 ?
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 quenpm
modifique el árbolnode_modules
opackage.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[.]