Yarn: O yarn.lock deve ser tratado como um arquivo binário no git?

Não, não deveria. O arquivo é um texto simples e pode haver conflitos de mesclagem no arquivo que você pode precisar resolver.

Na documentação está escrito que o arquivo yarn.lock não deve ser tocado para evitar problemas e apenas o próprio yarn deve lidar com ele. Então, como resolvo um conflito de mesclagem?

@kittens é a coisa certa a se fazer quando há conflitos para explodir o arquivo de bloqueio e executar o fio novamente? Parece que conseguiria o que você precisa?

@dbashford, o problema de soprar e yarn upgrade .

@dbashford então é mais fácil simplesmente colocar a linha. arquivo de bloqueio no gitignore

A abordagem que funcionou para mim até agora é esta:

git rebase origin/master

Quando o primeiro conflito surge, eu verifico o yarn.lock e reexecuto a instalação

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

Isso gera um novo yarn.lock base na versão original / master de yarn.lock , mas incluindo as alterações que fiz no meu package.json . Então é só uma questão de:

git add yarn.lock
git rebase --continue

E estou de volta aos negócios.

Observe que, mesmo que você não esteja resolvendo manualmente os conflitos de mesclagem, ter um arquivo não binário significa que você pode ver os conflitos de mesclagem, o que ainda é uma informação valiosa.

Relacionado, mesmo se não houver _não_ conflitos de mesclagem, podemos sempre assumir que git mesclou duas versões de um arquivo yarn.lock de uma forma que resulta em um arquivo válido / correto? Parece errado deixar o git atualizar o conteúdo do arquivo se yarn for a única ferramenta que deve gerenciar seu conteúdo.

Não tenho certeza se a geração automática de YAML sempre resultará em um arquivo válido, especialmente dado:

• Múltiplas versões principais no pacote que estão lado a lado no arquivo de bloqueio
• A primeira linha de duas entradas vizinhas pode mudar ao mesmo tempo enquanto é resolvida para a mesma versão ou uma versão semelhante:

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 Obrigado pelo passo a passo! Mas a preocupação de @idris ainda se aplica a esta solução. Você acabará atualizando muitas de suas dependências dessa maneira, o que pode ser inesperado.

@danny-andrews você pode explicar como?

Quando você limpa yarn.lock e executa novamente yarn install , todo o yarn.lock é reconstruído com as versões mais recentes das dependências que satisfazem os intervalos de versão especificados em package.json , efetivamente atualizar qualquer dependência que mudou desde a última execução yarn install .

É por isso que sugeri git checkout origin/master -- yarn.lock vez de excluir yarn.lock . Isso redefinirá seu yarn.lock para a versão no mestre, permitindo que yarn install atualize apenas os pacotes que foram alterados em seu package.json (e seus subdeps, é claro) .

@IanVS sim, essa é a maneira correta de fazer isso.

Embora eu recomende git checkout -- yarn.lock , que é mais geral e apenas redefine para o que estiver comprometido em seu branch atual.

Muito bem, @idris. Eu normalmente faço o realce no master, que é o exemplo que usei acima, mas nem sempre será o caso.

@IanVS Não entendi o que aquele comando fazia. Isso é muito melhor do que copiar e colar manualmente yarn.lock como tenho feito. Obrigado por compartilhar!

Isso está relacionado: # 3544

A abordagem de @IanVS não é compatível com ter o lockfile um arquivo binário? Se bem entendi, a ideia é nunca fundir, apenas jogue fora o que você tem e reproduza novamente seu yarn install em cima de qualquer yarn.lock já esteja presente no branch em que você está fundindo.

aqui está minha abordagem, para adicionar um 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"