Yarn: ¿Debería tratarse yarn.lock como un archivo binario en git?

No, no debería. El archivo es de texto sin formato y puede haber conflictos de combinación en el archivo que es posible que deba resolver.

En la documentación está escrito que el archivo yarn.lock no debe tocarse para evitar problemas y solo el hilo en sí debe tratarlo. Entonces, ¿cómo resuelvo un conflicto de fusión?

@kittens es lo correcto cuando hay conflictos para eliminar el archivo de bloqueo y volver a ejecutar el hilo? ¿Me parece que conseguiría lo que necesita?

@dbashford, el problema de soplarlo y volver a ejecutar el hilo es que obtendrá más cambios de los que deseaba. Por ejemplo, las versiones de tilde se actualizarán, aunque no haya ejecutado yarn upgrade .

@dbashford, entonces es más fácil simplemente poner el hilo. bloquear archivo en el gitignore

El enfoque que me ha funcionado hasta ahora es este:

git rebase origin/master

Cuando surge el primer conflicto, reviso yarn.lock luego vuelvo a realizar la instalación

git checkout origin/master -- yarn.lock
yarn install

Esto genera un nuevo yarn.lock basado en la versión original / maestra de yarn.lock , pero incluyendo los cambios que hice en mi package.json . Entonces es solo una cuestión de:

git add yarn.lock
git rebase --continue

Y estoy de vuelta en el negocio.

Tenga en cuenta que incluso si no está resolviendo manualmente los conflictos de fusión, tener un archivo no binario significa que puede ver los conflictos de fusión, que sigue siendo información valiosa.

Relacionado, incluso si hay _no_ conflictos de fusión, ¿podemos siempre asumir que git ha fusionado dos versiones de un archivo yarn.lock de una manera que da como resultado un archivo válido / correcto? Parece incorrecto permitir que git actualice el contenido del archivo si yarn es la única herramienta que se supone que administra su contenido.

No estoy seguro de que automatizar YAML siempre resulte en un archivo válido, especialmente dado:

• Varias versiones principales en el paquete que están una al lado de la otra en el archivo de bloqueo
• La primera línea de dos entradas vecinas puede cambiar al mismo tiempo mientras se resuelve en la misma versión o una similar:

readable-stream@^2.0.0, "readable-stream@^2.0.0 || ^1.1.13", readable-stream@^2.0.2, readable-stream@^2.0.5, readable-stream@^2.2.2:
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.2.2.tgz#a9e6fec3c7dda85f8bb1b3ba7028604556fc825e"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

readable-stream@~2.1.4:
  version "2.1.5"
  resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.1.5.tgz#66fa8b720e1438b364681f2ad1a63c618448c9d0"
  dependencies:
    buffer-shims "^1.0.0"
    core-util-is "~1.0.0"
    inherits "~2.0.1"
    isarray "~1.0.0"
    process-nextick-args "~1.0.6"
    string_decoder "~0.10.x"
    util-deprecate "~1.0.1"

@IanVS ¡ Gracias por el tutorial! Pero la preocupación de @idris todavía se aplica a esta solución. Terminará actualizando muchas de sus dependencias de esta manera, lo que puede ser inesperado.

@ danny-andrews, ¿puedes explicar cómo?

Cuando borra yarn.lock y vuelve a ejecutar yarn install , todo el yarn.lock se reconstruye con las versiones más recientes de las dependencias que satisfacen los rangos de versiones especificados en package.json , efectivamente actualizar cualquier dependencia que haya cambiado desde la última ejecución yarn install .

Por eso sugerí git checkout origin/master -- yarn.lock lugar de eliminar yarn.lock . Eso restablecerá su yarn.lock a la versión en el maestro, permitiendo que yarn install actualice solo los paquetes que han cambiado en su package.json (y sus subdepsitos, por supuesto) .

@IanVS sí, esa es la forma correcta de hacerlo.

Aunque recomendaría git checkout -- yarn.lock , que es más general y simplemente lo restablece a lo que esté comprometido en su rama actual.

Buen punto, @idris. Por lo general, rebaso en master, que es el ejemplo que usé anteriormente, pero ese no siempre será el caso.

@IanVS No entendí lo que hizo ese comando. Eso es mucho mejor que copiar y pegar manualmente yarn.lock como lo he estado haciendo. ¡Gracias por compartir!

Esto está relacionado: # 3544

¿No es el enfoque de @IanVS compatible con que el archivo de bloqueo sea un archivo binario? Si entiendo correctamente, la idea es no fusionar nunca, simplemente deseche lo que tiene y vuelva a reproducir su yarn install encima de lo que sea que yarn.lock ya esté presente en la rama en la que se está fusionando.

aquí está mi enfoque, para agregar un script bash

#!/usr/bin/env bash
export GIT_TRACE=1
git checkout origin/master -- Pipfile.lock Pipfile
git commit -m "fetch to branch Pipfile.lock, Pipfile from origin/master" -- Pipfile.lock Pipfile
read  -n 1 -p "Do your changes in Pipfile and press Enter ..."
pipenv lock --clear
git commit -m "re-apply changes to Pipfile.lock, Pipfile" -- Pipfile.lock Pipfile
echo "Done"