¿Debo confirmar el archivo yarn.lock y para qué sirve?

Yarn crea un yarn.lockarchivo después de realizar una yarn install.

¿Debería esto comprometerse con el repositorio o ignorarse? ¿Para qué sirve?

Sí, debe registrarlo, consulte Migrar desde npm

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.

Depende de cuál sea su proyecto:

1. ¿Tu proyecto es una aplicación? Entonces: si
2. ¿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.

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.

1. Los autores de dependencia pueden lanzar actualizaciones de la versión del parche y, de hecho, introducir un cambio importante que afectará su proyecto.

2. 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.

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.

Debieras:

1. agregarlo al repositorio y confirmarlo
2. 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

yarn installpuede mutar su hilo. Bloquear inesperadamente , haciendo que los reclamos de hilos de construcciones repetibles sean nulos y sin efecto. Solo debe usar yarn 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 :

yarn install

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.

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.

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.

También como Eric Elliott dijo aquí

No .gitignore hilo.lock. Está allí para garantizar una resolución de dependencia determinista para evitar errores de "funciona en mi máquina".

Sí, deberías cometerlo. Para obtener más información sobre el archivo yarn.lock, consulte los documentos oficiales aquí.

¡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).