Solución:
Almacena un árbol de dependencias exacto, versionado en lugar de usar versionado con estrellas como el propio package.json (por ejemplo, 1.0. *). Esto significa que puede garantizar las dependencias para otros desarrolladores o versiones de prod, etc. También tiene un mecanismo para bloquear el árbol, pero generalmente se regenerará si cambia package.json.
De los documentos de npm:
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 código fuente legibles.
Y optimice el proceso de instalación permitiendo que npm omita resoluciones de metadatos repetidas para paquetes instalados previamente “.
Editar
Para responder a la pregunta de jrahhali a continuación sobre el uso de package.json con números de versión exactos. Tenga en cuenta que su package.json contiene solo sus dependencias directas, no las dependencias de sus dependencias (a veces llamadas dependencias anidadas). Esto significa que con el package.json estándar no puede controlar las versiones de esas dependencias anidadas, hacer referencia a ellas directamente o como dependencias entre pares no ayudará, ya que tampoco controla la tolerancia de versión que sus dependencias directas definen para estas dependencias anidadas. .
Incluso si bloquea las versiones de sus dependencias directas, no puede garantizar al 100% que su árbol de dependencias completo será idéntico en todo momento. En segundo lugar, es posible que desee permitir cambios sin interrupciones (basados en el control de versiones semántico) de sus dependencias directas, lo que le brinda incluso menos control de las dependencias anidadas y, de nuevo, no puede garantizar que sus dependencias directas no rompan en algún momento las reglas de control de versiones semánticas. ellos mismos.
La solución a todo esto es el archivo de bloqueo que, como se describió anteriormente, bloquea las versiones del árbol de dependencia completo. Esto le permite garantizar su árbol de dependencias para otros desarrolladores o para lanzamientos y, al mismo tiempo, permite probar nuevas versiones de dependencias (directas o indirectas) utilizando su package.json estándar.
NÓTESE BIEN. El json de envoltura retráctil anterior hizo más o menos lo mismo, pero el archivo de bloqueo lo renombra para que su función sea más clara. Si ya hay un archivo de envoltura retráctil en el proyecto, se utilizará en lugar de cualquier archivo de bloqueo.
Es una mejora muy importante para npm: Garantizar exactamente la misma versión de cada paquete..
¿Cómo asegurarse de que su proyecto se construya con los mismos paquetes en diferentes entornos en un momento diferente? Digamos que puedes usar ^1.2.3 en tus package.json, o algunas de tus dependencias están usando de esa manera, pero ¿cómo puedes asegurarte cada vez npm install recogerá la misma versión en su máquina de desarrollo y en el servidor de compilación? package-lock.json se asegurará de eso.
npm install volverá a generar el archivo de bloqueo, cuando esté en el servidor de compilación o el servidor de implementación, haga npm ci (que leerá del archivo de bloqueo e instalará todo el árbol del paquete)
package-lock.json se escribe cuando se cambia un valor numérico en una propiedad, como la propiedad “versión”, o una propiedad de dependencia en package.json.
Si estos valores numéricos en package.json y package-lock.json fósforo, package-lock.json se lee.
Si estos valores numéricos en package.json y package-lock.json no coinciden, package-lock.json se escribe con esos nuevos valores y nuevos modificadores, como el signo de intercalación y la tilde, si están presentes. Pero es el número el que está desencadenando el cambio a package-lock.json.
Para ver lo que quiero decir, haga lo siguiente. Utilizando package.json sin package-lock.json, correr npm install con:
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "7.2.2"
}
}
package-lock.json ahora tendrá:
"sinon": {
"version": "7.2.2",
Ahora copie / pegue ambos archivos en un nuevo directorio. Cambio package.json a (solo agregando intercalación):
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.2.2"
}
}
correr npm install. Si no hubiera package-lock.json expediente, [email protected] sería instalado. npm install es leyendo de package-lock.json e instalación 7.2.2.
Ahora cambia package.json para:
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.3.0"
}
}
correr npm install. package-lock.json ha sido escrito a, y ahora mostrará:
"sinon": {
"version": "^7.3.0",