¿Por qué “npm install” reescribe package-lock.json?

Recientemente actualicé a npm @ 5 . Ahora tengo un archivo package-lock.json con todo, desde package.json . Esperaría que, cuando ejecuto, npm installlas versiones de dependencia se extraigan del archivo de bloqueo para determinar qué se debe instalar en mi directorio node_modules . Lo extraño es que en realidad termina modificando y reescribiendo mi archivo package-lock.json .

Por ejemplo, el archivo de bloqueo tenía especificado mecanografiado en la versión 2.1.6 . Luego, después del npm installcomando, la versión se cambió a 2.4.1 . Eso parece anular todo el propósito de un archivo de bloqueo.

¿Qué me estoy perdiendo? ¿Cómo consigo que npm respete realmente mi archivo de bloqueo?

Actualización 3: como también señalan otras respuestas, el npm cicomando se introdujo en npm 5.7.0 como una forma adicional de lograr compilaciones rápidas y reproducibles en el contexto de CI. Consulte la documentación y el blog de npm para obtener más información.

Actualización 2: el problema para actualizar y aclarar la documentación es el problema de GitHub # 18103 .

Actualización 1: el comportamiento que se describe a continuación se solucionó en npm 5.4.2: el comportamiento previsto actualmente se describe en el problema de GitHub # 17979 .

Respuesta original: el comportamiento de package-lock.jsonse cambió en npm 5.1.0 como se discutió en el número 16866 . El comportamiento que observa aparentemente está previsto por npm a partir de la versión 5.1.0.

Eso significa que se package.jsonpuede anular package-lock.jsonsiempre que se encuentre una versión más nueva para una dependencia en package.json. Si desea anclar sus dependencias de manera efectiva, ahora debe especificar las versiones sin un prefijo, por ejemplo, debe escribirlas como en 1.2.0lugar de ~1.2.0o ^1.2.0. Entonces la combinación de package.jsony package-lock.jsonproducirá construcciones reproducibles. Para ser claros: ¡ package-lock.jsonsolo ya no bloquea las dependencias de nivel raíz!

Si esta decisión de diseño fue buena o no es discutible, hay una discusión en curso resultante de esta confusión en GitHub en el número 17979 . (En mi opinión, es una decisión cuestionable; al menos el nombre lockya no es cierto).

Una nota al margen más: también hay una restricción para los registros que no admiten paquetes inmutables, como cuando extrae paquetes directamente de GitHub en lugar de npmjs.org. Consulte esta documentación de bloqueos de paquetes para obtener más explicaciones.

Descubrí que habrá una nueva versión de npm 5.7.1 con el nuevo comando npm ci, que se instalará package-lock.jsonsolo desde

El nuevo comando npm ci se instala SOLAMENTE desde su archivo de bloqueo. Si su package.json y su archivo de bloqueo no están sincronizados, informará un error.

Funciona desechando tus node_modules y recreándolos desde cero.

Más allá de garantizarle que solo obtendrá lo que está en su archivo de bloqueo, también es mucho más rápido (¡2x-10x!) Que npm install cuando no comienza con un node_modules.

Como puede deducir del nombre, esperamos que sea una gran ayuda para los entornos de integración continua. También esperamos que las personas que realicen implementaciones de producción desde etiquetas git vean importantes ganancias.

Utilice el recién introducido

npm ci

npm ci promete el mayor beneficio para los equipos grandes. Dar a los desarrolladores la capacidad de "firmar" un bloqueo de paquete promueve una colaboración más eficiente entre equipos grandes, y la capacidad de instalar exactamente lo que está en un archivo de bloqueo tiene el potencial de ahorrar decenas, si no cientos, de horas de desarrollador al mes, liberando equipos para pasar más tiempo construyendo y enviando cosas asombrosas.

Presentamos npm cipara compilaciones más rápidas y confiables

Respuesta corta:

• npm install acepta package-lock.json solo si satisface los requisitos de package.json.
• Si no satisface esos requisitos, los paquetes se actualizan y el bloqueo de paquete se sobrescribe.
• Si desea que la instalación falle en lugar de sobrescribir el bloqueo del paquete cuando esto suceda, use npm ci.

Aquí hay un escenario que podría explicar las cosas (verificado con NPM 6.3.0)

Declaras una dependencia en package.json como:

"depA": "^1.0.0"

Luego lo haces, npm installlo que generará un package-lock.json con:

"depA": "1.0.0"

Pocos días después, se lanza una versión secundaria más reciente de "depA", digamos "1.1.0", entonces se cumple lo siguiente:

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

A continuación, actualice manualmente su package.json a:

"depA": "^1.1.0"

Luego vuelva a ejecutar:

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

Utilice el npm cicomando en lugar de npm install.

"ci" significa "integración continua".

Instalará las dependencias del proyecto en función del archivo package-lock.json en lugar de las dependencias indulgentes del archivo package.json.

Producirá construcciones idénticas a las de tus compañeros de equipo y también es mucho más rápido.

Puede leer más sobre esto en esta publicación de blog: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

En el futuro, podrá usar un --from-lock-fileindicador (o similar) para instalar solo desde el package-lock.jsonsin modificarlo.

Esto será útil para entornos de CI, etc. donde las compilaciones reproducibles son importantes.

Consulte https://github.com/npm/npm/issues/18286 para realizar un seguimiento de la función.

Parece que este problema está solucionado en npm v5.4.2

https://github.com/npm/npm/issues/17979

(Desplácese hacia abajo hasta el último comentario del hilo)

Actualizar

Realmente arreglado en 5.6.0. Hubo un error multiplataforma en 5.4.2 que estaba causando que el problema siguiera ocurriendo.

https://github.com/npm/npm/issues/18712

Actualización 2

Vea mi respuesta aquí: https://stackoverflow.com/a/53680257/1611058

npm ci es el comando que debería usar al instalar proyectos existentes ahora.

Probablemente tengas algo como:

"typescript":"~2.1.6"

en su package.jsonqué npm se actualiza a la última versión menor, en su caso siendo2.4.1

Editar: Pregunta de OP

Pero eso no explica por qué "npm install" cambiaría el archivo de bloqueo. ¿No está el archivo de bloqueo destinado a crear una compilación reproducible? Si es así, independientemente del valor de semver, aún debería usar la misma versión 2.1.6.

Responder:

Esto tiene la intención de bloquear su árbol de dependencias completo. Digamos que typescript v2.4.1requiere widget ~v1.0.0. Cuando npm install, agarra widget v1.0.0. Más tarde, su compañero desarrollador (o compilación de CI) realiza una instalación de npm y obtiene, typescript v2.4.1pero widgetse ha actualizado a widget v1.0.1. Ahora su módulo de nodo no está sincronizado. Esto es lo que package-lock.jsonpreviene.

O más generalmente:

Como ejemplo, considere

paquete A:

{"nombre": "A", "versión": "0.1.0", "dependencias": {"B": "<0.1.0"}}

paquete B:

{"nombre": "B", "versión": "0.0.1", "dependencias": {"C": "<0.1.0"}}

y paquete C:

{"nombre": "C", "versión": "0.0.1"}

Si estas son las únicas versiones de A, B y C disponibles en el registro, se instalará una instalación normal de npm A:

[email protected] - [email protected] - [email protected]

Sin embargo, si se publica [email protected], se instalará una nueva instalación A de npm:

[email protected] - [email protected] - [email protected] asumiendo que la nueva versión no modificó las dependencias de B. Por supuesto, la nueva versión de B podría incluir una nueva versión de C y cualquier número de nuevas dependencias. Si tales cambios no son deseables, el autor de A podría especificar una dependencia en [email protected] Sin embargo, si el autor de A y el autor de B no son la misma persona, no hay forma de que el autor de A diga que no quiere incluir versiones recién publicadas de C cuando B no ha cambiado en absoluto.

OP Pregunta 2: Déjame ver si entiendo correctamente. Lo que está diciendo es que el archivo de bloqueo especifica las versiones de las dependencias secundarias, pero aún se basa en la coincidencia aproximada de package.json para determinar las dependencias de nivel superior. ¿Es eso exacto?

Respuesta: No. package-lock bloquea todo el árbol de paquetes, incluidos los paquetes raíz descritos en package.json. Si typescriptestá bloqueado 2.4.1en su package-lock.json, debe permanecer así hasta que se cambie. Y digamos que mañana typescriptlanza la versión 2.4.2. Si npm installreviso su rama y ejecuto , npm respetará el archivo de bloqueo e instalará 2.4.1.

Más sobre 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 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_modules sin 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.

https://docs.npmjs.com/files/package-lock.json

Probablemente deberías usar algo como esto

npm ci

En lugar de usar npm install si no desea cambiar la versión de su paquete.

De acuerdo con la documentación oficial, tanto npm installe npm ciinstalar las dependencias que son necesarias para el proyecto.

La principal diferencia es que npm installsí instala los paquetes tomando packge.jsoncomo referencia. Donde en el caso de npm cisí instala los paquetes tomando package-lock.jsoncomo referencia, asegurándose cada vez que se instala el paquete exacto.

Hay un problema abierto para esto en su página de github: https://github.com/npm/npm/issues/18712

Este problema es más grave cuando los desarrolladores utilizan diferentes sistemas operativos.

EDITAR: el nombre "bloqueo" es complicado, su NPM está tratando de ponerse al día con Yarn. No es un archivo bloqueado en absoluto. package.jsones un archivo corregido por el usuario, que una vez "instalado" generará el árbol de carpetas node_modules y ese árbol se escribirá en él package-lock.json. Como puede ver, es al revés: las versiones de dependencia se extraerán package.jsoncomo siempre y package-lock.jsondeben llamarsepackage-tree.json

(espero que esto haya aclarado mi respuesta, después de tantos votos negativos)

Una respuesta simplista: package.jsontenga sus dependencias como de costumbre, mientras que package-lock.jsones "un árbol de node_modules exacto y más importante reproducible" (tomado de npm docs ).

En cuanto al nombre complicado, su NPM está tratando de ponerse al día con Yarn.