Solución:
Sí, debe registrarlo, consulte Migración desde npm
¿Por qué es para eso?
El cliente npm instala dependencias en el node_modules directorio de forma no determinista. Esto significa que, según el orden en que se instalen las dependencias, la estructura de un directorio node_modules podría ser diferente de una persona a otra. Estas diferencias pueden causar funciona en mi maquina bichos que tardan mucho en cazar.
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 a una versión específica y garantizan que cada instalación dé como resultado exactamente la misma estructura de archivos en node_modules en todas las máquinas.
Depende de cuál sea tu proyecto:
- ¿Tu proyecto es una aplicación? Luego: sí
- ¿Tu proyecto es una biblioteca? Si es así: No
Se puede encontrar una descripción más elaborada de esto 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 el yarn.lock-se utilizará el archivo del proyecto de nivel superior. Entonces, a menos que el proyecto de uno se use de forma independiente y no se instale en otro proyecto, entonces no tiene sentido comprometer ningún yarn.lock-archivo: en su lugar, siempre dependerá del package.json-archivo para transmitir qué versiones de dependencias espera el proyecto en ese momento.
Veo que estas son dos preguntas separadas en una. Déjame responder a ambos.
¿Deberías 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. Sigue leyendo para entender por qué necesitas hacerlo.
Que 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 consistencia a 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 actualización de la dependencia, la última versión de la dependencia dentro del rango especificado (es decir, actualizaciones de parches sin interrupciones). Hay dos problemas con este enfoque.
-
Los autores de dependencias pueden publicar actualizaciones de la versión del parche y, de hecho, introducir un cambio importante que afectará a su proyecto.
-
Dos desarrolladores corriendo
npm installen diferentes momentos puede obtener el conjunto diferente de dependencias. Lo que puede hacer que un error no sea reproducible en dos entornos exactamente iguales. Esto podría causar problemas de estabilidad de compilación para los servidores de CI, por ejemplo.
El hilo, por otro lado, toma la ruta de la máxima previsibilidad. Crea yarn.lock archivo para guardar el exacto versiones de dependencia. Tener ese archivo en su lugar utilizará las versiones almacenadas en yarn.lock en lugar de resolver versiones de package.json. Esta estrategia garantiza que no ocurra ninguno de los problemas descritos anteriormente.
yarn.lock es parecido a npm-shrinkwrap.json que puede ser creado por npm shrinkwrap mando. Consulte esta respuesta para explicar las diferencias entre estos dos archivos.