Respostas:
Como é abordado em outro lugar, os arquivos de bloqueio de dependência, que são suportados por muitos sistemas de gerenciamento de pacote (por exemplo: composer e bundler ), devem ser comprometidos com a base de código em projetos de fim de cadeia - para que cada indivíduo que tente executar esse projeto esteja fazendo assim, exatamente com o conjunto testado de dependências.
É menos claro se os arquivos de bloqueio devem sempre ser confirmados em pacotes que devem ser incluídos em outros projetos (onde dependências mais livres são desejáveis). No entanto, tanto o Yarn quanto o NPM (conforme coberto por @Cyrille) ignoram de forma inteligente yarn.locke, package-lock.jsonrespectivamente, quando necessário, tornando seguro sempre enviar esses arquivos de bloqueio.
Portanto, você deve sempre comprometer pelo menos um yarn.lockoupackage-lock.json dependendo de qual gerenciador de pacotes está usando.
Neste momento temos dois sistemas de gerenciamento de pacotes diferentes, que tanto instalar o mesmo conjunto de dependências de package.json, mas que geram e ler a partir de dois lockfiles diferentes. NPM 5 gera package-lock.json, enquanto Yarn gera yarn.lock.
Se você se comprometer package-lock.json, estará construindo suporte para pessoas que instalam suas dependências com o NPM 5. Se você se comprometer yarn.lock, estará construindo suporte para pessoas que instalam dependências com Yarn.
Se você escolhe se comprometer yarn.lockou package-lock.jsonambos, depende se aqueles que estão desenvolvendo em seu projeto estão usando apenas Yarn ou NPM 5 ou ambos. Se o seu projeto for de código aberto, a coisa mais amigável a se fazer para a comunidade provavelmente seria comprometer ambos e ter um processo automatizado para garantir yarn.locke package-lock.jsonsempre ficar em sincronia.
Atualização: Yarn agora introduziu um importcomando que irá gerar um yarn.lockarquivo a partir de um package-lock.jsonarquivo. Isso pode ser útil para manter os dois arquivos sincronizados. (Obrigado @weakish)
Essas questões foram discutidas longamente no projeto Yarn em:
Ambos estão fechados agora.
Você deve confirmar 1 arquivo de bloqueio de árvore de dependência, mas não deve confirmar ambos. Isso também requer padronização em fio ou npm (não ambos) para construir + desenvolver um projeto.
Aqui está o artigo yarn sobre por que yarn.lock deve ser cometido, se você padronizar em yarn.
Se você confirmar ambos os yarn.lockarquivos E os package-lock.jsonarquivos, há várias maneiras de os 2 arquivos fornecerem árvores de dependência diferentes (mesmo se os algoritmos de resolução de árvore do yarn e do npm forem idênticos), e não é trivial garantir que eles fornecem exatamente o mesma resposta. Como não é trivial, é improvável que a mesma árvore de dependências seja mantida em ambos os arquivos, e você não quer um comportamento diferente dependendo se a construção foi feita usando yarn ou npm.
Se e quando o yarn mudar de usar yarn.lockpara package-lock.json( problema aqui ), a escolha do arquivo de bloqueio a ser confirmado torna-se fácil e não precisamos mais nos preocupar com o yarn e o npm resultando em compilações diferentes. Com base nesta postagem do blog , essa é uma mudança que não devemos esperar em breve (a postagem do blog também descreve as diferenças entre yarn.locke package-lock.json.
Eu estava pensando na mesma pergunta. Aqui estão meus pensamentos, espero que ajude:
A documentação do npm package-lock.json diz o seguinte:
package-lock.json é gerado automaticamente para qualquer operação em que o npm modifica a árvore node_modules ou package.json. Ele descreve a árvore exata que foi gerada, de forma que as instalações subsequentes possam gerar árvores idênticas, independentemente das atualizações de dependência intermediárias.
Isso é ótimo porque evita o efeito "funciona na minha máquina".
Sem este arquivo, se você npm install --save A, npm adicionará "A": "^1.2.3"ao seu package.json. Quando outra pessoa executa npm installem seu projeto, é possível que a versão 1.2.4do Atenha sido lançada. Uma vez que é a última versão disponível que satisfaz a faixa de sempre especificada em seu package.json, ele irá instalar esta versão. Mas e se houver um novo bug introduzido nesta versão? Essa pessoa vai ter um problema que você não consegue reproduzir porque tem a versão anterior, sem nenhum bug.
Ao corrigir o estado do seu node_modulesdiretório, o package-lock.jsonarquivo evita esse problema porque todos terão as mesmas versões de todos os pacotes.
Mas, e se você estiver escrevendo e publicando um módulo npm? A documentação diz o seguinte:
Um detalhe importante sobre o package-lock.json é que ele não pode ser publicado e será ignorado se for encontrado em qualquer lugar diferente do pacote de nível superior.
Então, mesmo que você faça commit, quando o usuário instalar o seu módulo, ele não vai pegar o package-lock.jsonarquivo, mas apenas o package.jsonarquivo. Portanto, o npm instalará a versão mais recente que satisfaça os intervalos de sempre de todas as suas dependências. Isso significa que você sempre deseja testar seu módulo com essas versões de suas dependências, e não aquela que você instalou quando começou a escrever seu módulo. Então, nesse caso, package-lock.jsoné claramente inútil. Mais, pode ser irritante.
Esta é minha regra prática: se você estiver trabalhando em um aplicativo, envie o (s) arquivo (s) de bloqueio. Se você estiver mantendo uma biblioteca, adicione-a à sua lista de ignorados. De qualquer maneira, você deve usar intervalos de semver precisos em package.json. Yehuda Katz (em cache ) escreveu uma ótima explicação de quando confirmar Gemfile.lock(arquivo de bloqueio do Ruby) e quando não. Pelo menos leia a seção tl; dr.
Você está certo! Permitir que ambos npme yarnsejam usados causará problemas. Dê uma olhada neste artigo .
Atualmente, estamos planejando adicionar alguns avisos para usuários que usam ambos
yarnenpmno mesmo repositório para instalar pacotes.É altamente recomendável que você exclua o
package-lock.jsonarquivo se decidir usar yarn para evitar futuras confusões e possíveis problemas de consistência.
Você não pode querer tanto npme yarncomo seu gerenciador de pacotes.
Esses arquivos são gerenciados por suas ferramentas, portanto - presumindo que o uso do yarn atualizará efetivamente o package-lock.json- suponho que enviar os dois arquivos funcione bem.
Acho que o mais importante para o seu usuário é package-lock.json(eu, por exemplo, não uso fio), então esse tem que ser confirmado.
Para o yarn.lock, depende se você trabalha sozinho ou em equipe. Se for solo, suponho que não haja necessidade de comprometê-lo. Se você (pretende) trabalhar em equipe, provavelmente deve comprometer-se, pelo menos até que o yarn dê suporte
Suponho que a equipe de fios acabará parando de usar yarn.locke usará package-json.lock, neste momento, ficará mais simples 😛
Não, o uso de ambos os arquivos de bloqueio simultaneamente geralmente resultará em inconsistências em sua árvore de dependências, especialmente ao colaborar em uma equipe. Ignorar um ou outro bloqueio é uma solução simples. Certifique-se de que sua equipe entende e concorda com essa mudança.