Devo confirmar o arquivo yarn.lock e para que serve?

305

O fio cria um yarn.lockarquivo após a execução de um yarn install.

Isso deve ser confirmado no repositório ou ignorado? Para que serve?

yarnpkg 
— rlay3
fonte
3
IMHO, esta pergunta (e a maioria das respostas abaixo) está incompleta devido à falta da pergunta "Como e quando devemos regenerar o arquivo yarn.lock?"
— 21718 MarkHu
1
Você sabe agora como e quando?
— Jayarjo #
@ MarkHu encontrou-o aqui: yarnpkg.com/lang/pt/docs/yarn-lock/#toc-managed-by-yarn Então, basicamente:Your yarn.lock file is auto-generated and should be handled entirely by Yarn. As you add/upgrade/remove dependencies with the Yarn CLI, it will automatically update your yarn.lock file.
— jayarjo 18/18/18 /
— k0pernikus

Respostas:

271

Sim, você deve fazer check-in, consulte Migrando do npm

O Yarn irá gerar um arquivo yarn.lock no diretório raiz do seu pacote. Você não precisa ler ou entender esse arquivo - basta verificar no controle de origem.

— ckuijjer
fonte
33
Bom achado. Eu encontrei o seguinte em seus documentos que responde "para que serve?": "O cliente npm instala dependências no diretório node_modules de forma não determinística. Isso significa que, com base nas dependências de pedidos, a estrutura de um node_modules O diretório pode ser diferente de uma pessoa para outra. Essas diferenças podem causar erros de "trabalhos em minha máquina" que demoram muito tempo para serem encontrados ".
— rlay3
13
Continua: "O Yarn resolve esses problemas em torno de controle de versão e não determinismo usando arquivos de bloqueio e um algoritmo de instalação determinístico e confiável. Esses arquivos de bloqueio bloqueiam as dependências instaladas em uma versão específica e garantem que cada instalação resulte exatamente na mesma estrutura de arquivos em node_modules em todas as máquinas. "
— rlay3
Em vez de dizer "nenhum arquivo de bloqueio encontrado". Deveria apenas dizer "Gerando arquivo yarn.lock". Duh :) Não é um erro, mas o primeiro parece um erro. E o último será alarmante o suficiente para qualquer pessoa no cenário inverso (onde eles esperam ter um arquivo yarn.lock, mas aparentemente não).
— Alexander Mills
7
Aprecio que o yarn.lock está bloqueando nosso projeto para versões específicas de pacotes, mas acho que o uso da palavra "lock" é lamentável. Geralmente, os arquivos de bloqueio (como .ldb ) são um meio de limitar um recurso a um processo de cada vez, para evitar que as atualizações que intercedam corrompidas possam causar. Esses arquivos de bloqueio definitivamente não devem ser comprometidos com o controle de versão, que é possivelmente o local de maior parte da confusão sobre o yarn.lock.
— Antony
2
Eu realmente não gosto da frase "você não precisa ler ou entender este arquivo". Este é um arquivo importante para manter seu projeto.
— Nathan Goings
83

Depende do seu projeto:

  1. O seu projeto é uma aplicação? Então: Sim
  2. O seu projeto é uma biblioteca? Se sim: Não

Uma descrição mais elaborada disso pode ser encontrada nesta edição do GitHub, em que um dos criadores do Yarn, por exemplo. diz:

O package.json descreve as versões pretendidas desejadas pelo autor original, enquanto yarn.lock descreve a última configuração válida para um determinado aplicativo.

Somente o yarn.lockarquivo-do projeto de nível superior será usado. Portanto, a menos que um projeto seja usado de forma independente e não seja instalado em outro projeto, não há utilidade em confirmar nenhum yarn.lockarquivo -file - em vez disso, sempre estará disponível o package.jsonarquivo -f para transmitir quais versões de dependências o projeto espera então.

— VoxPelli
fonte
7
Por outro lado, o fato de o arquivo de bloqueio em projetos de biblioteca não influenciar a reprodutibilidade de seus respectivos testes?
— E_net4 gosta de downvotes
1
Se eu li sua descrição corretamente, então "O seu projeto é uma biblioteca?" pode ser respondido com "Se você quiser". Não parece ter desvantagens, mas pode ser útil se você tiver devDependencies complexos e desejar que todos os desenvolvedores da sua lib tenham os mesmos scripts de compilação e teste. Certo?
— Pipo
4
Como o arquivo de bloqueio não será respeitado por todos os usuários de sua biblioteca, em seguida, contar com ela ao desenvolver a biblioteca poderia dar uma falsa sensação de segurança
— VoxPelli
1
O Dart possui o mesmo sistema com pubspec.yaml e pubspec.lock e recomenda o mesmo que na resposta. Veja esta pergunta e esta entrada da documentação.
— Jonas Kello
16
Por favor, veja esta entrada no blog oficial do Yarn: Arquivos de bloqueio devem ser confirmados em todos os projetos
— E_net4 gosta de downvotes
66

Vejo que essas são duas perguntas separadas em uma. Deixe-me responder as duas.

Você deve confirmar o arquivo no repositório?

Sim. Conforme mencionado na resposta do ckuijjer , é recomendável no Guia de migração incluir esse arquivo no repositório. Leia para entender por que você precisa fazer isso.

O que é yarn.lock?

É um arquivo que armazena as versões exatas de dependência para o seu projeto, juntamente com somas de verificação para cada pacote. Esta é a maneira do fio de fornecer consistência para suas dependências.

Para entender por que esse arquivo é necessário, primeiro você precisa entender qual era o problema por trás dos NPMs originais package.json. Quando você instala o pacote, o NPM armazena o intervalo de revisões permitidas de uma dependência em vez de uma revisão específica (semver). O NPM tentará buscar a atualização da dependência da versão mais recente da dependência dentro do intervalo especificado (ou seja, atualizações de patch sem interrupção). Há dois problemas com esta abordagem.

  1. Os autores de dependência podem lançar atualizações de versão de patch, enquanto na verdade introduzem uma alteração que afetará seu projeto.

  2. Dois desenvolvedores executando npm installem momentos diferentes podem obter o conjunto diferente de dependências. O que pode fazer com que um bug não seja reproduzível em dois ambientes exatamente iguais. Isso pode causar problemas de estabilidade de compilação para servidores de CI, por exemplo.

O fio, por outro lado, segue o caminho da máxima previsibilidade. Ele cria um yarn.lockarquivo para salvar as versões exatas da dependência. Tendo esse arquivo no lugar, o fio usará as versões armazenadas em yarn.lockvez de resolver as versões package.json. Essa estratégia garante que nenhum dos problemas descritos acima aconteça.

yarn.locké semelhante ao npm-shrinkwrap.jsonque pode ser criado por npm shrinkwrapcomando. Verifique esta resposta explicando as diferenças entre esses dois arquivos.

— Juriy
fonte
1
Mas vejo yarn.lockser atualizado de vez em quando, você sabe por que e quando yarnfaz isso?
— Jayarjo #
1
Os problemas de fios # 4379 e # 4147 sugerem yarnatualizações yarn.lockem muitos casos, incluindo a execução yarn installsem alterações no package.json. Usar yarn install --frozen-lockfilecomo sugerido em Por que rodar o yarn no Windows altera o yarn.lock (ou configurá-lo via .yarnrc) parece ser a melhor aposta.
— Lauri Harpf 10/10/19
Atualmente, o npm possui a package-lock.jsone a npm ci. Esse fluxo de trabalho é de fios yarn.locke análogos yarn install --frozen-lockfile.
— k0pernikus 27/09/19
8

Você deve:

  1. adicione-o ao repositório e confirme
  2. use yarn install --frozen-lockfilee NOT yarn installcomo padrão localmente e em servidores de criação de IC.

(Abri um ticket no rastreador de problemas do fio para defender o comportamento padrão do arquivo de bloqueio congelado, consulte # 4147 ).

Cuidado para NÃO definir o frozen-lockfilesinalizador no .yarnrcarquivo, pois isso impediria que você pudesse sincronizar o arquivo package.json e yarn.lock. Veja a questão do fio relacionado no github

yarn installpode alterar seu yarn.lock inesperadamente , tornando nula e sem efeito reivindicações de compilação repetível. Você só deve usaryarn install para inicializar um yarn.lock e atualizá-lo.

Além disso, esp. em equipes maiores, você pode ter muito barulho em torno das alterações no bloqueio do fio apenas porque um desenvolvedor estava configurando seu projeto local.

Para obter mais informações, leia minha resposta sobre o pacote-lock.json do npm , que também se aplica aqui.

Isso também foi esclarecido recentemente nos documentos para instalação de fios :

yarn install

Instale todas as dependências listadas em package.json na pasta node_modules local.

O yarn.lockarquivo é utilizado da seguinte maneira:

  • Se yarn.lock estiver presente e for suficiente para satisfazer todas as dependências listadas em package.json, as versões exatas registradas em yarn.lock serão instaladas e o yarn.lock permanecerá inalterado. O fio não procurará versões mais recentes.
  • Se yarn.lock estiver ausente ou não for suficiente para satisfazer todas as dependências listadas em package.json (por exemplo, se você adicionar manualmente uma dependência a package.json), o Yarn procurará as versões mais recentes disponíveis que satisfazem as restrições do pacote .json. Os resultados são gravados em yarn.lock.

Se você deseja garantir que yarn.lock não seja atualizado, use --frozen-lockfile.

— k0pernikus
fonte
Embora seja verdade, o único momento em que posso pensar que você precisaria usar --frozen-lockfileé se alguém atualizasse o package.json manualmente sem executar yarn installe confirmar as atualizações posteriormente . Portanto, um IC pode querer usar esse sinalizador, mas os desenvolvedores não devem, porque ocultam os problemas.
— jkrehm 03/02
@jkrehm Depende do que você quer dizer com ocultar problemas. Eu tive mais problemas com yarn.lockarquivos alterados inesperadamente introduzidos por yarn installinchaço de solicitações pull ou por causar conflitos desnecessários de mesclagem ou por puxar uma biblioteca com falha. (Somente porque uma biblioteca usa semvar, não significa que um patch / atualização menor não interrompa seu aplicativo - eu já estive lá). Considero que a atualização yarn.lockdeve ser apenas uma etapa manual, e é por isso que confio yarn install --frozen-lockfile(e npm ciem projetos npm) até na minha máquina de desenvolvimento, pois é confiável e determinística.
— k0pernikus
1
Nunca tive problemas com yarn.locka atualização inesperada (uso desde outubro de 2016, quando foi lançado). Sempre foi um usuário fazendo algo manualmente ou um script pós-instalação ruim. É a razão pela qual prefiro Yarn sobre NPM (o NPM atualiza tudo o que você quiser). Acho que me considero afortunado por não ter encontrado essas questões.
— jkrehm 7/02
5

Da minha experiência, eu diria que sim, devemos confirmar o yarn.lockarquivo. Isso garantirá que, quando outras pessoas usarem o seu projeto, elas obtenham as mesmas dependências esperadas pelo seu projeto.

Do Doc

Quando você executa yarn ou yarn add, o Yarn gera um arquivo yarn.lock no diretório raiz do seu pacote. Você não precisa ler ou entender esse arquivo - basta verificar no controle de origem. Quando outras pessoas começarem a usar o Yarn em vez do npm, o arquivo yarn.lock garantirá que elas obtenham exatamente as mesmas dependências que você possui.

Alguém poderia argumentar que podemos alcançá-lo substituindo ^por --. Sim, podemos, mas, em geral, vimos que a maioria dos npmpacotes vem com ^notação e precisamos alterar a notação manualmente para garantir a versão da dependência estática.yarn.lock .

Também como Eric Elliott disse aqui

Não .gitignore yarn.lock. Ele existe para garantir a resolução determinística da dependência, a fim de evitar erros "funciona na minha máquina".

— Anshul
fonte
3

Sim, você deve cometer. Para saber mais sobre o arquivo yarn.lock, consulte os documentos oficiais aqui

— Navin prasad
fonte
3

Sim! yarn.lockdeve ser verificado para que qualquer desenvolvedor que instale as dependências obtenha exatamente a mesma saída! Com o npm [disponível em outubro de 2016] , por exemplo, você pode ter uma patchversão (por exemplo, 1.2.0) instalada localmente, enquanto um novo desenvolvedor executando um novo installpode obter uma versão diferente (1.2.1).

— enapupe
fonte
1
O comportamento do npm que você mencionou depende de como você salva suas dependências. Se você salvar --save-exactao usar o npm, poderá obter o mesmo comportamento.
— AlicanC
4
@ AlicanC Eu não acho tão simples assim. Eu acredito que o yarn (através de um arquivo de bloqueio comprometido) garantirá a mesma versão dos pacotes e todas as suas dependências também . Isso é algo com o qual o NPM sempre teve problemas, porque a dependência de uma dependência pode não estar fixada em uma versão específica, portanto uma nova instalação pode gerar dependências de nível inferior diferentes. O shrinkwrap do NPM deveria resolver esse problema até certo ponto, mas sempre foi complicado e muitas vezes não funciona corretamente.
— nextgentech
@nextgentech Se, nesse caso, como faço para garantir que a dependência da dependência seja atualizada corretamente. Suponha que se eu tenho um pacote principal que possui alguns (digamos 3) pacotes dependentes. Observarei as alterações no meu pacote principal e atualizo-o no package.json. Mas se algum dos 3 subpacotes for atualizado por eles, como receberei as alterações? Por causa do arquivo de bloqueio, essas dependências não serão atualizadas, certo?
— Pragatheeswaran
Ainda não brinquei muito com isso, mas acredito que é aí que o yarn upgradecomando entra em ação. Este comando atualizará todos os pacotes e recriará o arquivo de bloqueio. Portanto, por exemplo, se você estiver implantando um aplicativo em produção e precisar instalar as dependências, ele o faria com base no arquivo de bloqueio retirado do repositório. Você nunca deve executar, a yarn upgrademenos que queira explicitamente alterar as informações de dependência (e assim confirmar um novo arquivo de bloqueio).
— nextgentech
yarn installnão garantirá as mesmas versões. Só yarn install --frozen-lockfilefaz.
— k0pernikus 27/09/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.