Yarn: Devo precisar colocar yarn.lock em .gitignore?

Você deve adicionar yarn.lock ao seu git , não o ignore.

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

Quando você executa yarn ou yarn add <package> , o Yarn irá gerar um arquivo yarn.lock no diretório raiz do seu pacote. Você não precisa ler ou entender este arquivo - apenas verifique-o no controle de origem . Quando outras pessoas começarem a usar o Yarn em vez de npm , o arquivo yarn.lock garantirá que eles obtenham exatamente as mesmas dependências que você.

Só para ficar claro - isso também se aplica a bibliotecas e não apenas a aplicativos, porque ao contrário de npm-shrinkwrap.json apenas o yarn.lock do projeto de nível superior será usado, certo? Portanto, dependências de dependências com arquivos yarn.lock não irão gerar duplicatas desnecessárias. É útil para bibliotecas, se você tiver dependências de desenvolvimento complexas e quiser que todos os contribuidores de sua biblioteca tenham as mesmas configurações de construção e teste.

Isso está correto?

@goenning
Talvez nem sempre seja a melhor ideia colocar o arquivo yarn.lock em seu repositório.
Por exemplo, estou usando sinopia. Portanto, tenho um registro npm personalizado. Eu uso este registro principalmente para outros projetos onde tenho módulos privados.
Mas quando eu envio um projeto público para um repositório git, que tem apenas dependências públicas, o yarn.lock tem os links errados para as dependências e meu sistema de CI não consegue construir o projeto.
As dependências apontam para meu repositório local.
Isso também pode acontecer com outros desenvolvedores se eles clonarem meu repositório.
Existe alguma maneira de contornar isso, exceto colocar o arquivo yarn.lock no gitignore?

Além disso, se você tiver pré-autenticado o registro npm, por exemplo, myget que atua como proxy para npm, yarn.lock terá links pré-autenticados para pacotes, o que é uma grande violação de segurança 🎉
Isso deve ser documentado em algum lugar com uma fonte grande.

@Pfeifenjoy e se você vincular a pacotes privados usando o submódulo git em vez de npm?
usando git, você pode acessar o repo usando a chave de implantação (via ssh)

@beenotung Não sou um grande fã de usar o git como gerenciador de dependências, pois ele é muito lento, não resolve dependências da maneira que eu quero e na minha opinião é melhor ter todas as dependências em um gerenciador.

Além disso, todas as dependências que estou referenciando (não apenas meus próprios projetos) receberão um endereço diferente, porque estão salvas na minha conta local da sinopia. Seria muito tedioso fazer referência a todos os módulos de nó dos quais meus projetos dependem no git.
Além disso, é apenas mais fácil remover o arquivo yarn.lock.

@Pfeifenjoy Existe possivelmente um conflito entre o que você deseja que o fio faça? Se você quiser fornecer uma maneira de garantir que outras instalações tenham suas dependências, inclua-a - ela está funcionando conforme o esperado. Se você está puxando repositórios e fontes privados, você deve ser muito cauteloso sobre como você compartilha seu código por digamos, da mesma forma que você especificamente ignoraria quaisquer chaves ou sais de um repo (se você quiser ver um aviso no leia-me do projeto, eu faria uma solicitação de recurso / pull).

Possivelmente, o yarn deve dar um aviso ao ser executado, alertando um usuário de que o acesso a uma fonte autenticada foi incluído no arquivo de bloqueio, mas, novamente, isso seria uma solicitação de recurso.

@thisolivier parece razoável

Apenas um memorando.
Por causa de https://github.com/yarnpkg/yarn/issues/3330 , se você mora na China ou outra área restrita, e constrói seu módulo com outro registro (eq taobao), você deve adicionar yarn.lock para .gitignore e escreva package-lock = false em .npmrc.

Aqui porque eu não coloco meu yarn.lock é gerado).
para manter meus usuários felizes e com uma instalação sem bugs, eu removo o fio - a menos que o fio forneça uma solução com uma documentação clara como resolver isso, eu concordo então.
(sempre ouça do desenvolvedor a verdadeira história)

Também torna seus commits realmente feios.

Não concordo com o comentário mais votado aqui:

• se o projeto usar npm, comprometa package-lock.json para o repo e gitignore yarn.lock
• se o projeto usar yarn, comprometa yarn.lock para o repo e gitignore package-lock.json

Ou seja, você _não_ deve sempre enviar yarn.lock ao repo e, para responder à pergunta do OP, sim , você pode querer adicioná-lo a .gitignore .

Quando outras pessoas começarem a usar o Yarn em vez do npm, o arquivo yarn.lock garantirá que eles obtenham exatamente as mesmas dependências que você

Em primeiro lugar, não vai - apenas se você usar apenas o registro público do npm. Pior se você não estiver autenticado em sua organização privada no yarn (mesmo se ainda estiver no npm), e um pacote com o mesmo nome existir no registro público, ele apenas instalará o errado sem prompt. Seria confuso por que seu yarn está instalando sem erros, mas o aplicativo não funciona ao usar o yarn, mas funciona ao usar o npm.

Em segundo lugar, muitas bases de código _não_ usam yarn. Não é uma questão de "quando eles mudam para fio". Quase todos os meus serviços de nó e servidores web básicos usam npm sem planos de mudar para o yarn. Eu gosto de falar com React, só isso.

Como @Pfeifenjoy mencionado acima:

Eu tenho um registro npm personalizado. Eu uso este registro principalmente para outros projetos onde tenho módulos privados

Mas quando eu envio um projeto público para um repositório git, que tem apenas dependências públicas, o yarn.lock tem os links errados para as dependências e meu sistema de CI não consegue construir o projeto.

^ Outra coisa, mesmo quando você resolve localmente, você tem que incorporar a solução ao yaml ou qualquer outra configuração para CI e em qualquer outro lugar em que você acione o aplicativo - algum tipo de lógica que pode dizer quando usar qual registro e qual comando - parece irritante e desnecessário

Outra coisa - se você encorajar todos a sempre comprometer yarn.lock para o repo e nunca ignorá-lo, os desenvolvedores começarão a usar o yarn em um repo que já depende fortemente do npm. Mesmo nos casos em que funciona bem, haverá redundâncias nos 2 arquivos de bloqueio, e isso abrirá uma porta para o inferno da dependência. E você sabe que algum desenvolvedor comprometerá uma linha de ~ 25k yarn.lock em algum ponto bagunçando seu gráfico de contribuições: alegria: