Yarn: ¿Debería poner yarn.lock en .gitignore?

Deberías agregar yarn.lock a tu git , no lo

Ver https://yarnpkg.com/en/docs/migrating-from-npm

Cuando ejecuta yarn o yarn add <package> , Yarn generará un archivo yarn.lock dentro del directorio raíz de su paquete. No es necesario que lea o comprenda este archivo, simplemente compruébelo en el control de código fuente . Cuando otras personas comiencen a usar Yarn en lugar de npm , el archivo yarn.lock garantizará que obtengan exactamente las mismas dependencias que usted.

Para ser claros, esto también se aplica a las bibliotecas y no solo a las aplicaciones, porque al contrario de npm-shrinkwrap.json solo se usará el yarn.lock del proyecto de nivel superior, ¿verdad? Por lo tanto, las dependencias de dependencias con archivos yarn.lock no generarán duplicados innecesarios. Es útil para bibliotecas, si tiene dependencias de desarrollo complejas y desea que todos los contribuyentes de su biblioteca tengan las mismas configuraciones de compilación y prueba.

¿Es esto correcto?

@goenning
Quizás no siempre sea la mejor idea poner el archivo yarn.lock en su repositorio.
Por ejemplo, estoy usando sinopia. Por lo tanto, tengo un registro npm personalizado. Utilizo este registro principalmente para otros proyectos en los que tengo módulos privados.
Pero cuando envío un proyecto público a un repositorio de git, que solo tiene dependencias públicas, yarn.lock tiene los enlaces incorrectos a las dependencias y mi sistema de CI no podrá compilar el proyecto.
Las dependencias apuntan a mi repositorio local.
Esto también les puede pasar a otros desarrolladores si clonan mi repositorio.
¿Hay alguna forma de evitar esto excepto poniendo el archivo yarn.lock en el gitignore?

Además, si tiene un registro npm previamente autenticado, por ejemplo, myget which proxy a npm, yarn.lock tendrá enlaces previamente autenticados a paquetes, lo cual es una importante brecha de seguridad 🎉
Esto debe documentarse en algún lugar con una fuente grande.

@Pfeifenjoy, ¿qué
usando git, puede acceder al repositorio usando la clave de implementación (a través de ssh)

@beenotung No soy un gran fanático de usar git como administrador de dependencias, porque es muy lento, no resuelve las dependencias de la forma en que quiero que se resuelvan y, en mi opinión, es mejor tener todas las dependencias en un solo administrador.

Además, la dependencia a la que estoy haciendo referencia tendrá todas (no solo mis propios proyectos) una dirección diferente, porque se guardan en mi cuenta local de sinopia. Sería muy tedioso hacer referencia a todos los módulos de nodo de los que dependen mis proyectos en git.
Además, es más fácil eliminar el archivo yarn.lock.

@Pfeifenjoy ¿Existe posiblemente un conflicto en lo que quieres que haga el hilo? Si desea proporcionar una forma de asegurarse de que otras instalaciones tengan sus dependencias, inclúyala, está funcionando según lo previsto. Si está obteniendo repositorios y fuentes privados, debe tener mucho cuidado con la forma en que comparte su código por ejemplo, de la misma manera que ignoraría específicamente las claves o sales de un repositorio (si desea ver un advertencia en el archivo Léame del proyecto, haría una función / solicitud de extracción).

Posiblemente, yarn debería dar una advertencia cuando se ejecute, alertando a un usuario de que el acceso a una fuente autenticada se ha incluido en el archivo de bloqueo, pero nuevamente, esa sería una solicitud de función.

@thisolivier suena razonable

Solo una nota.
Debido a https://github.com/yarnpkg/yarn/issues/3330 , si vive en China u otra área restringida y crea su módulo con otro registro (eq taobao), debe agregar yarn.lock a .gitignore y escriba package-lock = false en .npmrc.

Aquí por qué no confirmo mi yarn.lock ).
Para mantener contentos a mis usuarios y una instalación sin errores, elimino el hilo; a menos que el hilo proporcione una solución con una documentación clara sobre cómo resolver esto, estaré de acuerdo en ese momento.
(escuche siempre del desarrollador la historia real)

También hace que tus confirmaciones sean realmente feas.

No estoy de acuerdo con el comentario más votado aquí:

• si el proyecto usa npm, confirme package-lock.json en el repositorio y gitignore yarn.lock
• si el proyecto usa hilo, confirme yarn.lock en el repositorio y gitignore package-lock.json

Es decir, _no_ debe enviar siempre yarn.lock al repositorio , y para responder a la pregunta de OP, sí , es posible que desee agregarlo a .gitignore .

Cuando otras personas comiencen a usar Yarn en lugar de npm, el archivo yarn.lock se asegurará de que obtengan exactamente las mismas dependencias que usted.

En primer lugar, no, no lo hará, solo si solo está utilizando el registro público de npm. Peor aún, si no está autorizado a su organización privada en yarn (incluso si todavía está en npm), y existe un paquete con el mismo nombre en el registro público, simplemente instalará el incorrecto sin aviso. Sería confuso por qué su hilo se instala sin errores, sin embargo, la aplicación no funciona cuando se usa hilo, pero sí cuando se usa npm.

En segundo lugar, muchas bases de código _no_ usan hilo. No se trata de "cuándo se cambian al hilo". Casi todos mis servicios de nodo y servidores web básicos usan npm sin planes de pasar a hilo. Me gusta el hilo con React, eso es todo.

Como @Pfeifenjoy mencionó anteriormente:

Tengo un registro npm personalizado. Utilizo este registro principalmente para otros proyectos donde tengo módulos privados

Pero cuando envío un proyecto público a un repositorio de git, que solo tiene dependencias públicas, yarn.lock tiene los enlaces incorrectos a las dependencias y mi sistema de CI no podrá compilar el proyecto.

^ Otra cosa, incluso cuando lo resuelve localmente, debe incorporar la solución en el yaml o cualquier configuración para CI y en cualquier otro lugar donde active la aplicación, algún tipo de lógica que pueda decir cuándo usar qué registro y qué comando - suena molesto e innecesario

Otra cosa: si alienta a todos a que siempre asignen yarn.lock al repositorio y nunca lo ignoren, los desarrolladores comenzarán a usar hilo en un repositorio que ya depende en gran medida de npm. Incluso en los casos en los que funciona bien, habrá redundancias en los 2 archivos de bloqueo y se abrirá una puerta al infierno de la dependencia. Y sabes que algún desarrollador enviará una línea de ~ 25k yarn.lock en algún momento arruinando tu gráfico de contribuciones: alegría: