En mi humilde opinión, esta pregunta (y la mayoría de las respuestas a continuación) están incompletas debido a que falta la pregunta de "¿Cómo y cuándo debemos regenerar el archivo yarn.lock?"
MarkHu
1
¿Sabes ahora cómo y cuándo?
jayarjo
@MarkHu lo encontró aquí: yarnpkg.com/lang/en/docs/yarn-lock/#toc-managed-by-yarn Así que básicamente:Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.
Yarn generará un archivo yarn.lock dentro del directorio raíz de su paquete. No es necesario que lea o comprenda este archivo, simplemente instálelo en el control de código fuente.
Buen hallazgo He encontrado lo siguiente en sus documentos que responde "¿para qué sirve?": "El cliente npm instala las dependencias en el directorio node_modules de forma no determinista. Esto significa que, en función del orden en que se instalan las dependencias, la estructura de un node_modules el directorio podría ser diferente de una persona a otra. Estas diferencias pueden causar errores de "funciona en mi máquina" que tardan mucho tiempo en cazar ".
rlay3
13
Continúa: "Yarn resuelve estos problemas relacionados con el control de versiones y el no determinismo mediante el uso de archivos de bloqueo y un algoritmo de instalación que es determinista y confiable. Estos archivos de bloqueo bloquean las dependencias instaladas en una versión específica y aseguran que cada instalación tenga exactamente la misma estructura de archivos en node_modules en todas las máquinas ".
rlay3
En lugar de decir "no se encontró el archivo de bloqueo". Simplemente debería decir "Generando archivo yarn.lock". Duh :) No es un error, pero el primero suena como un error. Y este último será lo suficientemente alarmante para cualquier persona en el escenario inverso (donde esperan tener un archivo yarn.lock, pero aparentemente no).
Alexander Mills, el
77
Aprecio yarn.lock está bloqueando nuestro proyecto a versiones específicas del paquete, pero siento que el uso de la palabra "bloqueo" es lamentable. Por lo general, los archivos de bloqueo (como .ldb ) son un medio de limitar un recurso a un proceso a la vez para evitar la corrupción que pueden causar las actualizaciones que interceden. Tales archivos de bloqueo definitivamente no deberían comprometerse con el control de versiones, que es posiblemente de donde proviene la mayor parte de la confusión sobre yarn.lock.
Antony
2
Realmente no me gusta la frase "no necesitas leer o entender este archivo". Este es un archivo importante para mantener su proyecto.
Nathan Goings
83
Depende de cuál sea su proyecto:
¿Tu proyecto es una aplicación? Entonces: si
¿Tu proyecto es una biblioteca? Si es así: no
Una descripción más elaborada de esto se puede encontrar en este número de GitHub donde uno de los creadores de Yarn, por ejemplo. dice:
Package.json describe las versiones previstas deseadas por el autor original, mientras que yarn.lock describe la última configuración válida conocida para una aplicación determinada.
Solo se yarn.lockutilizará el archivo del proyecto de nivel superior. Por lo tanto, a menos que los proyectos se usen de forma independiente y no se instalen en otro proyecto, entonces no tiene sentido comprometer ningún yarn.lockarchivo; en su lugar, siempre package.jsondependerá del archivo transmitir qué versiones de dependencias espera el proyecto en ese momento.
Por otro lado, ¿no tener el archivo de bloqueo en proyectos de biblioteca influiría en la reproducibilidad de sus respectivas pruebas?
E_net4 le gustan los votos negativos el
1
Si leo su descripción correctamente, que "¿Su proyecto es una biblioteca?" podría responderse con "Si quieres". No parece tener inconvenientes, pero podría ser útil si tiene dependencias de desarrollo complejas y desea que cada desarrollador de su lib tenga los mismos scripts de compilación y prueba. ¿Correcto?
Pipo
44
Como el archivo de bloqueo no será respetado por ningún usuario de su biblioteca, confiar en él cuando desarrolle la biblioteca podría dar una falsa sensación de seguridad
VoxPelli
1
Dart tiene el mismo sistema con pubspec.yaml y pubspec.lock y recomienda lo mismo que en la respuesta. Vea esta pregunta y esta entrada de documentación.
Veo que estas son dos preguntas separadas en una. Déjame responder a ambas.
¿Debería enviar el archivo al repositorio?
Si. Como se menciona en la respuesta de ckuijjer, se recomienda en la Guía de migración incluir este archivo en el repositorio. Siga leyendo para comprender por qué necesita hacerlo.
¿Qué es yarn.lock?
Es un archivo que almacena las versiones de dependencia exactas para su proyecto junto con sumas de verificación para cada paquete. Esta es la forma de hilo para proporcionar coherencia para sus dependencias.
Para comprender por qué se necesita este archivo, primero debe comprender cuál era el problema detrás de los NPM originales package.json. Cuando instale el paquete, NPM almacenará el rango de revisiones permitidas de una dependencia en lugar de una revisión específica (semver). NPM intentará recuperar la última versión de dependencia de la dependencia dentro del rango especificado (es decir, actualizaciones de parches sin interrupciones). Hay dos problemas con este enfoque.
Los autores de dependencia pueden lanzar actualizaciones de la versión del parche y, de hecho, introducir un cambio importante que afectará su proyecto.
Dos desarrolladores que se ejecutan npm installen diferentes momentos pueden obtener un conjunto diferente de dependencias. Lo que puede causar que un error no sea reproducible en dos entornos exactamente iguales. Esto podría causar problemas de estabilidad de compilación para servidores CI, por ejemplo.
El hilo, por otro lado, toma la ruta de la máxima previsibilidad. Crea un yarn.lockarchivo para guardar las versiones de dependencia exactas . Tener ese archivo en su lugar usará versiones almacenadas en yarn.locklugar de resolver versiones de package.json. Esta estrategia garantiza que ninguno de los problemas descritos anteriormente suceda.
yarn.lockes similar a lo npm-shrinkwrap.jsonque se puede crear por npm shrinkwrapcomando. Verifique esta respuesta explicando las diferencias entre estos dos archivos.
Pero veo que yarn.lockse actualiza de vez en cuando, ¿sabes por qué y cuándo yarn?
jayarjo
1
Los problemas de hilo # 4379 y # 4147 sugieren que las yarnactualizaciones yarn.locken muchos casos, incluida la ejecución yarn installsin cambios en package.json. Usar yarn install --frozen-lockfilecomo se sugiere en Por qué ejecutar yarn en Windows cambia yarn.lock (o configurarlo a través de .yarnrc) parece ser la mejor opción.
Lauri Harpf
npm hoy en día tiene a package-lock.jsony a npm ci. Ese flujo de trabajo es de hilo análogo yarn.locky yarn install --frozen-lockfile.
use yarn install --frozen-lockfiley NO yarn installcomo un valor predeterminado tanto localmente como en servidores de compilación de CI.
(Abrí un ticket en el rastreador de problemas de hilo para hacer un caso para hacer el comportamiento predeterminado de archivo congelado, ver # 4147 ).
Tenga cuidado de NO establecer la frozen-lockfilebandera en el .yarnrcarchivo ya que eso le impedirá poder sincronizar el archivo package.json y yarn.lock. Ver el tema de hilo relacionado en github
Además, esp. En equipos más grandes, es posible que haya mucho ruido alrededor de los cambios en el bloqueo de hilo solo porque un desarrollador estaba configurando su proyecto local.
Instale todas las dependencias enumeradas en package.json en la carpeta local node_modules.
El yarn.lockarchivo se utiliza de la siguiente manera:
Si yarn.lock está presente y es suficiente para satisfacer todas las dependencias enumeradas en package.json, se instalan las versiones exactas registradas en yarn.lock y yarn.lock no cambiará. Yarn no buscará nuevas versiones.
Si yarn.lock está ausente o no es suficiente para satisfacer todas las dependencias enumeradas en package.json (por ejemplo, si agrega manualmente una dependencia a package.json), Yarn busca las versiones más recientes disponibles que satisfagan las restricciones del paquete .json. Los resultados se escriben en yarn.lock.
Si desea asegurarse de que yarn.lock no esté actualizado, use --frozen-lockfile.
Aunque es verdad, la única vez que puedo pensar que usted tiene a su uso --frozen-lockfilees si alguien actualiza manualmente package.json sin que a continuación se ejecuta yarn instally cometiendo las actualizaciones. Por lo tanto, un CI puede querer usar esa bandera, pero los desarrolladores no deberían hacerlo porque oculta los problemas.
jkrehm
@jkrehm Depende de lo que quieras decir con ocultar problemas. Tuve más problemas con yarn.lockarchivos inesperadamente cambiados introducidos por yarn install, ya sea por solicitudes de extracción hinchadas, o por causar conflictos de fusión innecesarios, o al extraer una biblioteca de última hora. (Solo porque una biblioteca usa semvar, no significa que un parche / actualización menor no rompa su aplicación, he estado allí). Considero que la actualización yarn.locksolo debe ser un paso manual, por eso me baso yarn install --frozen-lockfile(y npm cien proyectos npm) incluso en mi máquina de desarrollo, ya que es confiable y determinista.
k0pernikus
1
Nunca he tenido un problema con la yarn.lockactualización inesperada ( he estado usando desde octubre de 2016 cuando salió). Siempre ha sido un usuario que hace algo manualmente o un pésimo script posterior a la instalación. Es la razón por la que prefiero Yarn sobre NPM (NPM actualiza todo lo que quiera). Creo que me consideraré afortunado de no haberme topado con esos problemas.
jkrehm
5
Desde mi experiencia, diría que sí, deberíamos confirmar el yarn.lockarchivo. Asegurará que, cuando otras personas usen su proyecto, obtengan las mismas dependencias que su proyecto esperaba.
Cuando ejecuta yarn o yarn add, Yarn generará un archivo yarn.lock dentro del directorio raíz de su paquete. No es necesario que lea o comprenda este archivo, simplemente instálelo en el control de código fuente. Cuando otras personas comienzan a usar Yarn en lugar de npm, el archivo yarn.lock asegurará que obtengan exactamente las mismas dependencias que usted.
Un argumento podría ser que podemos lograrlo reemplazando ^con --. Sí, podemos, pero en general, hemos visto que la mayoría de los npmpaquetes vienen con ^notación, y tenemos que cambiar la notación manualmente para garantizar la versión de dependencia estática. Pero si usayarn.lock asegurará programáticamente su versión correcta.
¡Si! yarn.lockdebe registrarse para que cualquier desarrollador que instale las dependencias obtenga exactamente el mismo resultado. Con npm [que estaba disponible en octubre de 2016] , por ejemplo, puede tener una patchversión (por ejemplo, 1.2.0) instalada localmente, mientras que un nuevo desarrollador que ejecuta una installversión nueva podría obtener una versión diferente (1.2.1).
El comportamiento npm que mencionó depende de cómo guarde sus dependencias. Si ahorra con --save-exactcuando usa npm, puede lograr el mismo comportamiento.
AlicanC
44
@AlicanC No creo que sea tan simple. Creo que yarn (a través de un archivo de bloqueo comprometido) garantizará la misma versión de los paquetes y todas sus dependencias también . Esto es algo con lo que NPM siempre ha tenido un problema, porque una dependencia de una dependencia podría no estar anclada a una versión específica, por lo que una nueva instalación podría atraer diferentes dependencias de nivel inferior. Se suponía que la envoltura retráctil de NPM resolvería este problema hasta cierto punto, pero siempre fue complicado y muy a menudo no funciona correctamente.
nextgentech
@nextgentech Si en ese caso, ¿cómo me aseguro de que la dependencia de la dependencia se actualice correctamente? Supongamos que tengo un paquete principal que tiene algunos (digamos 3) paquetes dependientes. Observaré los cambios en mi paquete principal y lo actualizaré en package.json. Pero si alguno de los 3 subpaquetes es actualizado por ellos, ¿cómo obtendré los cambios? Debido al archivo de bloqueo, esas dependencias no se actualizarán, ¿verdad?
Pragatheeswaran
Todavía no lo he jugado mucho, pero creo que ahí es donde yarn upgradeentra en juego el comando. Este comando actualizará todos los paquetes y volverá a crear el archivo de bloqueo. Entonces, por ejemplo, si está implementando una aplicación en producción y necesita instalar las dependencias, lo haría en función del archivo de bloqueo extraído del repositorio. Nunca debe ejecutarse a yarn upgrademenos que desee explícitamente cambiar la información de dependencia (y así confirmar un nuevo archivo de bloqueo).
nextgentech
yarn installNo asegurará las mismas versiones. Solo lo yarn install --frozen-lockfilehace.
Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.Respuestas:
Sí, debe registrarlo, consulte Migrar desde npm
fuente
Depende de cuál sea su proyecto:
Una descripción más elaborada de esto se puede encontrar en este número de GitHub donde uno de los creadores de Yarn, por ejemplo. dice:
Solo se
yarn.lockutilizará el archivo del proyecto de nivel superior. Por lo tanto, a menos que los proyectos se usen de forma independiente y no se instalen en otro proyecto, entonces no tiene sentido comprometer ningúnyarn.lockarchivo; en su lugar, siemprepackage.jsondependerá del archivo transmitir qué versiones de dependencias espera el proyecto en ese momento.fuente
Veo que estas son dos preguntas separadas en una. Déjame responder a ambas.
¿Debería enviar el archivo al repositorio?
Si. Como se menciona en la respuesta de ckuijjer, se recomienda en la Guía de migración incluir este archivo en el repositorio. Siga leyendo para comprender por qué necesita hacerlo.
¿Qué es
yarn.lock?Es un archivo que almacena las versiones de dependencia exactas para su proyecto junto con sumas de verificación para cada paquete. Esta es la forma de hilo para proporcionar coherencia para sus dependencias.
Para comprender por qué se necesita este archivo, primero debe comprender cuál era el problema detrás de los NPM originales
package.json. Cuando instale el paquete, NPM almacenará el rango de revisiones permitidas de una dependencia en lugar de una revisión específica (semver). NPM intentará recuperar la última versión de dependencia de la dependencia dentro del rango especificado (es decir, actualizaciones de parches sin interrupciones). Hay dos problemas con este enfoque.Los autores de dependencia pueden lanzar actualizaciones de la versión del parche y, de hecho, introducir un cambio importante que afectará su proyecto.
Dos desarrolladores que se ejecutan
npm installen diferentes momentos pueden obtener un conjunto diferente de dependencias. Lo que puede causar que un error no sea reproducible en dos entornos exactamente iguales. Esto podría causar problemas de estabilidad de compilación para servidores CI, por ejemplo.El hilo, por otro lado, toma la ruta de la máxima previsibilidad. Crea un
yarn.lockarchivo para guardar las versiones de dependencia exactas . Tener ese archivo en su lugar usará versiones almacenadas enyarn.locklugar de resolver versiones depackage.json. Esta estrategia garantiza que ninguno de los problemas descritos anteriormente suceda.yarn.lockes similar a lonpm-shrinkwrap.jsonque se puede crear pornpm shrinkwrapcomando. Verifique esta respuesta explicando las diferencias entre estos dos archivos.fuente
yarn.lockse actualiza de vez en cuando, ¿sabes por qué y cuándoyarn?yarnactualizacionesyarn.locken muchos casos, incluida la ejecuciónyarn installsin cambios en package.json. Usaryarn install --frozen-lockfilecomo se sugiere en Por qué ejecutar yarn en Windows cambia yarn.lock (o configurarlo a través de.yarnrc) parece ser la mejor opción.package-lock.jsony anpm ci. Ese flujo de trabajo es de hilo análogoyarn.lockyyarn install --frozen-lockfile.Supongo que sí, ya que Yarn versiona su propio archivo yarn.lock: https://github.com/yarnpkg/yarn
Se utiliza para la resolución determinista de dependencias de paquetes.
fuente
Debieras:
yarn install --frozen-lockfiley NOyarn installcomo un valor predeterminado tanto localmente como en servidores de compilación de CI.(Abrí un ticket en el rastreador de problemas de hilo para hacer un caso para hacer el comportamiento predeterminado de archivo congelado, ver # 4147 ).
Tenga cuidado de NO establecer la
frozen-lockfilebandera en el.yarnrcarchivo ya que eso le impedirá poder sincronizar el archivo package.json y yarn.lock. Ver el tema de hilo relacionado en githubyarn installpuede mutar su hilo. Bloquear inesperadamente , haciendo que los reclamos de hilos de construcciones repetibles sean nulos y sin efecto. Solo debe usaryarn installpara inicializar yarn.lock y actualizarlo.Además, esp. En equipos más grandes, es posible que haya mucho ruido alrededor de los cambios en el bloqueo de hilo solo porque un desarrollador estaba configurando su proyecto local.
Para obtener más información, lea mi respuesta sobre el paquete-lock.json de npm, ya que eso también se aplica aquí.
Esto también se aclaró recientemente en los documentos para la instalación de hilo :
fuente
--frozen-lockfilees si alguien actualiza manualmente package.json sin que a continuación se ejecutayarn instally cometiendo las actualizaciones. Por lo tanto, un CI puede querer usar esa bandera, pero los desarrolladores no deberían hacerlo porque oculta los problemas.yarn.lockarchivos inesperadamente cambiados introducidos poryarn install, ya sea por solicitudes de extracción hinchadas, o por causar conflictos de fusión innecesarios, o al extraer una biblioteca de última hora. (Solo porque una biblioteca usa semvar, no significa que un parche / actualización menor no rompa su aplicación, he estado allí). Considero que la actualizaciónyarn.locksolo debe ser un paso manual, por eso me basoyarn install --frozen-lockfile(ynpm cien proyectos npm) incluso en mi máquina de desarrollo, ya que es confiable y determinista.yarn.lockactualización inesperada ( he estado usando desde octubre de 2016 cuando salió). Siempre ha sido un usuario que hace algo manualmente o un pésimo script posterior a la instalación. Es la razón por la que prefiero Yarn sobre NPM (NPM actualiza todo lo que quiera). Creo que me consideraré afortunado de no haberme topado con esos problemas.Desde mi experiencia, diría que sí, deberíamos confirmar el
yarn.lockarchivo. Asegurará que, cuando otras personas usen su proyecto, obtengan las mismas dependencias que su proyecto esperaba.Del doc.
Un argumento podría ser que podemos lograrlo reemplazando
^con--. Sí, podemos, pero en general, hemos visto que la mayoría de losnpmpaquetes vienen con^notación, y tenemos que cambiar la notación manualmente para garantizar la versión de dependencia estática. Pero si usayarn.lockasegurará programáticamente su versión correcta.También como Eric Elliott dijo aquí
fuente
Sí, deberías cometerlo. Para obtener más información sobre el archivo yarn.lock, consulte los documentos oficiales aquí.
fuente
¡Si!
yarn.lockdebe registrarse para que cualquier desarrollador que instale las dependencias obtenga exactamente el mismo resultado. Con npm [que estaba disponible en octubre de 2016] , por ejemplo, puede tener unapatchversión (por ejemplo, 1.2.0) instalada localmente, mientras que un nuevo desarrollador que ejecuta unainstallversión nueva podría obtener una versión diferente (1.2.1).fuente
--save-exactcuando usa npm, puede lograr el mismo comportamiento.yarn upgradeentra en juego el comando. Este comando actualizará todos los paquetes y volverá a crear el archivo de bloqueo. Entonces, por ejemplo, si está implementando una aplicación en producción y necesita instalar las dependencias, lo haría en función del archivo de bloqueo extraído del repositorio. Nunca debe ejecutarse ayarn upgrademenos que desee explícitamente cambiar la información de dependencia (y así confirmar un nuevo archivo de bloqueo).yarn installNo asegurará las mismas versiones. Solo loyarn install --frozen-lockfilehace.