¿Cuál es la diferencia entre npm-shrinkwrap.json y package-lock.json?

Question

Con el lanzamiento de npm @ 5 , ahora escribirá un package-lock.json menos que ya exista un npm-shrinkwrap.json .

Instalé npm @ 5 a nivel mundial a través de:

npm install npm@5 -g

Y ahora, si se encuentra un npm-shrinkwrap.json durante:

npm install

se imprimirá una advertencia:

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I''ll try to do my best with it!

Entonces, mi package-lock.json es que debería reemplazar la package-lock.json con el package-lock.json .

Sin embargo, ¿por qué hay un nuevo formato para ello? ¿Qué puede hacer el package-lock.json que npm-shrinkwrap.json no puede hacer?

Answer 1

Creo que la idea era hacer que --save y shrinkwrap sucedan de forma predeterminada, pero evite cualquier problema potencial con un shrinkwrap que ocurra donde no se quería. Entonces, simplemente le dieron un nuevo nombre de archivo para evitar conflictos. Alguien de npm lo explicó más a fondo aquí:

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

La cita relevante:

npm publica la mayoría de los archivos en su directorio fuente de manera predeterminada, y las personas han estado publicando shrinkwraps durante años. No queríamos romper la compatibilidad. Con --save y shrinkwrap por defecto, existía un gran riesgo de que accidentalmente ingresara y se propagara a través del registro, y básicamente dejaba nula nuestra capacidad para actualizar los departamentos y deduplicar ...

Entonces elegimos un nuevo nombre. Y elegimos un nuevo nombre de repente. El nuevo archivo de bloqueo comparte básicamente todo el mismo código, exactamente el mismo formato

Answer 2

Los archivos tienen exactamente el mismo contenido, pero hay algunas diferencias en cómo npm los maneja, descritos en el sitio de documentos y también en un archivo de documentos en el repositorio de npm que comienza abordando explícitamente la diferencia entre estos dos archivos :

• package-lock.json nunca se publica en npm, mientras que npm-shrinkwrap es por defecto
• package-lock.json archivos package-lock.json que no están en el paquete de nivel superior, pero se package-lock.json archivos package-lock.json que pertenecen a dependencias
• npm-shrinkwrap.json es compatible con versiones anteriores de npm 2, 3 y 4, mientras que package-lock.json solo es reconocido por npm 5+

Puede convertir un package-lock.json existente en npm-shrinkwrap.json ejecutando npm shrinkwrap .

Así:

• Si no está publicando su paquete en npm, la elección entre estos dos archivos es de poca importancia. Es posible que desee utilizar package-lock.json porque es el valor predeterminado y su nombre es más claro para los principiantes de npm; alternativamente, es posible que desee utilizar npm-shrinkwrap.json para la compatibilidad con versiones anteriores de npm 2-4 si le resulta difícil asegurarse de que todos en su equipo de desarrollo estén en npm 5+. (Tenga en cuenta que npm 5 se lanzó el 25 de mayo de 2017; la compatibilidad con versiones anteriores será cada vez menos importante a medida que avancemos a partir de esa fecha, ya que la mayoría de las personas eventualmente se actualizarán).

• Si está publicando su paquete en npm, puede elegir entre:

  1. usando un package-lock.json para registrar exactamente qué versiones de dependencias instaló, pero permitiendo que las personas que instalen su paquete usen cualquier versión de las dependencias que sea compatible con los rangos de versión dictados por su package.json , o
  2. usando npm-shrinkwrap.json para garantizar que todos los que instalen su paquete obtengan exactamente la misma versión de todas las dependencias

  
  La opinión oficial descrita (muy brevemente) en los documentos es que la opción 1 debe usarse para las bibliotecas (presumiblemente para reducir la cantidad de duplicación de paquetes causada cuando muchas de las dependencias de un paquete dependen de versiones ligeramente diferentes de la misma dependencia secundaria) , pero esa opción 2 podría ser razonable para los ejecutables que se instalarán globalmente.

Answer 3

Explicación del desarrollador de NPM :

La idea es definitivamente que package-lock.json sea el último y el más grande en tecnología shrinkwrap, y npm-shrinkwrap.json esté reservado para esas pocas personas preciosas que se preocupan mucho por que sus bibliotecas tengan un nodo_módulo exacto, y para las personas que desean que CI use npm @> = 2 para instalar un árbol en particular sin tener que cambiar su versión npm.

El nuevo archivo de bloqueo ("package-lock.json") comparte básicamente todo el mismo código, exactamente el mismo formato que npm-shrinkwrap (¡puede cambiarles el nombre entre ellos!). También es algo que la comunidad parece entender: "tiene un archivo de bloqueo" parece hacer clic mucho más rápido con las personas. Finalmente, tener un nuevo archivo significaba que podíamos tener compatibilidad con versiones anteriores de riesgo relativamente bajo con una envoltura retráctil sin tener que hacer cosas raras como permitir la publicación mencionada en la publicación principal.