npm @ 5 ha sido publicado, tiene una nueva característica package-lock.json file (after npm install) que me confunde. Quiero saber, ¿cuál es el efecto de este archivo?
npm @ 5 ha sido publicado, tiene una nueva característica package-lock.json file (after npm install) que me confunde. Quiero saber, ¿cuál es el efecto de este archivo?
Respuestas:
Almacena un árbol de dependencias exacto y versionado en lugar de usar versiones destacadas como package.json (por ejemplo, 1.0. *). Esto significa que puede garantizar las dependencias para otros desarrolladores o lanzamientos de productos, etc. También tiene un mecanismo para bloquear el árbol, pero generalmente se regenerará si cambia package.json.
De los documentos 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 confirmado en repositorios de origen y sirve para varios propósitos:
Describa una representación única de un árbol de dependencias de modo que se garantice que los compañeros de equipo, las implementaciones y la integración continua instalen 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 de árbol a través de diferencias de control de fuente legible.
Y optimice el proceso de instalación permitiendo que npm omita las resoluciones de metadatos repetidos para paquetes instalados previamente ".
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 paquete estándar.json no puede controlar las versiones de esas dependencias anidadas, hacer referencia a ellas directamente o las dependencias pares no ayudarán, 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 sea idéntico cada vez. En segundo lugar, es posible que desee permitir cambios sin interrupciones (basados en versiones semánticas) de sus dependencias directas, lo que le brinda aún menos control de las dependencias anidadas, además de que no puede garantizar que sus dependencias directas no rompan en algún momento las reglas de versiones semánticas. sí mismos.
La solución a todo esto es el archivo de bloqueo que, como se describió anteriormente, bloquea en las versiones del árbol de dependencias completo. Esto le permite garantizar su árbol de dependencias para otros desarrolladores o para versiones, al tiempo que permite probar nuevas versiones de dependencias (directas o indirectas) utilizando su package.json estándar.
NÓTESE BIEN. El anterior Jink Shrink Wrap hizo casi lo mismo, pero el archivo de bloqueo lo renombra para que su función sea más clara. Si ya hay un archivo retráctil en el proyecto, se utilizará en lugar de cualquier archivo de bloqueo.
package-lock.jsonarchivo se actualiza cada vez que llama a npm install desde NPM 5.1. (cambio en github.com/npm/npm/issues/16866 , ejemplo en github.com/npm/npm/issues/17979 ) Por lo tanto, ya no se puede usar para configurar las mismas versiones para todos los desarrolladores , a menos que especifique versiones exactas como en 1.2.3lugar de 1.2.*en su package.jsonarchivo.
npm cicomo npm installactualizará el paquete-lock.json mientras que ci usa su contenido. Solo con npm ciusted obtendrá construcciones robustas y repetibles.
Es una mejora muy importante para npm: garantiza exactamente la misma versión de cada paquete .
¿Cómo asegurarse de que su proyecto se construyó con los mismos paquetes en diferentes entornos en un momento diferente? Digamos que puede usarlo ^1.2.3en su package.json, o algunas de sus dependencias lo están usando de esa manera, pero ¿cómo puede asegurarse de que cada vez npm installelija 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 installvolverá a generar el archivo de bloqueo, cuando esté en el servidor de compilación o en el servidor de implementación, haga npm ci(que leerá el archivo de bloqueo e instalará todo el árbol del paquete)
package-lock.jsonen absoluto el archivo. Simplemente se instala package.jsoncomo solía hacerlo. Para utilizar el package-lock.jsonarchivo, debe utilizar el nuevo comando "npm ci", que instalará las versiones exactas enumeradas en package-lock.jsonlugar de los rangos de versiones indicados package.json.
npm install no leer package-lock.json. Para reproducir, haga lo siguiente. usando este package.json, ejecute npm install{... "devDependencies": {"sinon": "7.2.2"}} Ahora copie / pegue package.jsony package-lock.jsonen un nuevo directorio. Cambie package.jsona: "sinon": "^ 7.2.2" ejecutar npm install. npm lee desde package-lock.json e instala 7.2.2 en lugar de 7.3.0. Sin package-lock.json, se instalaría 7.3.0.
package-lock.json, la única forma razonable de hacerlo es eliminarlo package-lock.jsony regenerarlo usando npm install. (No desea editar manualmente package-lock.json). Cambiar el valor de la propiedad "versión" (cerca de la parte superior) de package.jsoncambiará lo mismo en package-lock.jsonon npm install, pero agregar un cursor a una dependencia no hará lo mismo package-lock.json.
package.jsonen algo que puede modificar manualmente y package-lock.jsoncomo algo que nunca toca manualmente. Siempre controlas la versión de AMBOS archivos, especialmente package-lock.json. Abra ambos archivos, edite manualmente el nombre del proyecto package.json, ejecute npm instally observe cómo cambia el nombre del proyecto package-lock.json. licenseno parece ser registrada en package-lock.json.
npm ci, npm installsolo usará package.json, aunque se proporcione el archivo de bloqueo
package-lock.json se escribe cuando un valor numérico en una propiedad como la propiedad "versión" o una propiedad de dependencia se cambia en package.json .
Si estos valores numéricos en package.jsonypackage-lock.json coinciden, package-lock.jsonse lee de.
Si estos valores numéricos en package.jsony package-lock.jsonno coinciden,package-lock.json se escribe con esos nuevos valores y con nuevos modificadores como el cursor y la tilde si están presentes. Pero es el número el que está activando el cambio package-lock.json.
Para ver a qué me refiero, haga lo siguiente. Utilizando package.jsonsin package-lock.json, ejecutar npm installcon:
{
"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. Cambiar package.jsona (solo agregando intercalación):
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.2.2"
}
}
ejecutar npm install. Si no hubiera ningún package-lock.jsonarchivo, se instalaría sinon@7.3.0. npm installestá leyendo de package-lock.json e instalando 7.2.2.
Ahora cambie package.jsona:
{
"name": "test",
"version": "1.0.0",
...
"devDependencies": {
"sinon": "^7.3.0"
}
}
ejecutar npm install. package-lock.jsonha sido escrito y ahora mostrará:
"sinon": {
"version": "^7.3.0",
Una cosa importante a mencionar también es la mejora de seguridad que viene con el archivo de bloqueo de paquete. Dado que mantiene todos los hashes de los paquetes si alguien manipula el registro público npm y cambia el código fuente de un paquete sin siquiera cambiar la versión del paquete, el archivo de bloqueo del paquete lo detectará.
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.
Describe una representación única de un árbol de dependencias de modo que se garantiza que los compañeros de equipo, las implementaciones y la integración continua instalen exactamente las mismas dependencias. Contiene las siguientes propiedades.
{
"name": "mobileapp",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"@angular-devkit/architect": {
"version": "0.11.4",
"resolved": "https://registry.npmjs.org/@angular- devkit/architect/-/architect-0.11.4.tgz",
"integrity": "sha512-2zi6S9tPlk52vyqNFg==",
"dev": true,
"requires": {
"@angular-devkit/core": "7.1.4",
"rxjs": "6.3.3"
}
},
}
Npm crea y utiliza este archivo automáticamente para realizar un seguimiento de las instalaciones de sus paquetes y para gestionar mejor el estado y el historial de las dependencias de su proyecto. No debe alterar el contenido de este archivo.
package-lock.json: contiene los detalles exactos de la versión que está instalada actualmente para su aplicación.