javascript - O arquivo package-lock.json deve ser adicionado ao .gitignore?

Para bloquear as versões das dependências que são instaladas em um projeto, o comando npm install cria um arquivo chamado package-lock.json. Isso foi feito desde o Node.js v8.0.0 e o npm v5.0.0, como muitos de vocês devem saber.

Apesar das recomendações do Node.js e do npm sobre a necessidade de commitar este arquivo, várias preocupações sobre quando você deve evitar fazê-lo também são uma opção. Normalmente nós committamos em nossos projetos, no entanto, é uma questão peculiar.

Embora devamos commitar o arquivo package-lock.json por padrão, temos um caso específico em que não devemos. Por exemplo, se quisermos testar a versão mais recente das dependências do nosso projeto, pode ser uma opção adicionar package-lock.json ao .gitignore.

Então, as perguntas são as seguintes:

1. O arquivo package-lock.json deve ser adicionado ao .gitignore?
2. Existe alguma situação em particular em que DEVEMOS ou NÃO DEVEMOS fazê-lo?

Resposta #1

Não, o package-lock.json NÃO DEVE ser adicionado ao .gitignore. Em vez disso, recomendo fortemente:

1. Adicione o package-lock.json ao seu repositório de controle de versão
2. Use npm ci em vez de npm install ao construir sua aplicação tanto localmente quanto no seu pipeline de implantação.
   (O comando ci está disponível desde [email , se houver dúvida, atualize seu npm via:
   npm install -g npm.)

Uma das maiores desvantagens do comando npm install é seu comportamento inesperado, que pode modificar o package-lock.json, enquanto o npm ci usa apenas a versão no arquivo de bloqueio e produz um erro se o package-lock.json e o package.json estiverem fora de sincronização.

Além disso, npm ci exige a existência de um package-lock.json e exibiria um erro se ele não estivesse presente. Há um forte caso de uso para poder confiar que as dependências do projeto são resolvidas de forma consistente e confiável em diferentes máquinas.

Além disso, npm ci destrói toda a pasta node_modules antes de adicionar as dependências, garantindo que você trabalhe com suas dependências reais em vez de mudanças locais, sendo ainda mais rápido que um npm install normal.

A partir de um package-lock.json, você obtém exatamente isso: um estado conhecido por funcionar com sempre exatamente a mesma árvore de dependências.

No passado, eu tinha projetos sem arquivos package-lock.json/npm-shrinkwrap.json/yarn.lock cujo build falharia algum dia porque uma dependência aleatória recebeu uma atualização com quebra. (Embora muitas bibliotecas respeitem a diretriz de versionamento semântico, você não tem garantia de que elas não quebrem em uma atualização menor.)

Esses problemas são difíceis de resolver, pois às vezes você precisa adivinhar qual foi a última versão que funcionou.

Em relação a testar as dependências mais recentes do seu projeto: É para isso que serve o npm update e afirmo que ele deve ser executado por um desenvolvedor, que também execute o teste localmente, que resolva problemas caso eles surjam, e que então faça o commit do package-lock.json alterado. (Se uma atualização falhar, eles podem reverter para o último package-lock.json funcionando.)

Além disso, raramente atualizo todas as dependências de uma vez (já que isso também pode exigir manutenção adicional), mas prefiro escolher individualmente a atualização que preciso (por exemplo, npm update {dependency}, ou npm install {dependency}@2.1.3). O que é outro motivo pelo qual eu veria isso como uma etapa de manutenção manual.

Se você realmente quiser automatizá-lo, você poderia criar um trabalho para:

• verificar repositório
• executar npm update

• executar testes

  • se os testes passarem, então faça commit e envie para o repositório
  • caso contrário, falhe e reporte o problema para ser resolvido manualmente

Isso é algo que eu veria hospedado em um servidor CI, por exemplo, Jenkins, e não deve ser alcançado pelo motivo mencionado anteriormente através da adição do arquivo ao .gitignore.

Ou para citar a documentação do npm:

É altamente recomendado que você faça o commit do arquivo de bloqueio de pacotes gerado no controle de versão: isso permitirá que qualquer outra pessoa da sua equipe, seus deployments, sua integração contínua (CI) e qualquer pessoa que execute npm install no seu código fonte obtenha exatamente a mesma árvore de dependências na qual você estava desenvolvendo. Além disso, as diferenças resultantes dessas mudanças são legíveis por humanos e irão informá-lo sobre quaisquer alterações que o npm tenha feito em seus node_modules, para que você possa perceber se alguma dependência transitiva foi atualizada, promovida, etc.

E em relação à diferença entre npm ci e npm install:

• O projeto deve ter um package-lock.json ou npm-shrinkwrap.json existente.
• Se as dependências no package lock não corresponderem àquelas no package.json, npm ci será encerrado com um erro, em vez de atualizar o package lock.
• npm ci só pode instalar projetos inteiros de uma vez: dependências individuais não podem ser adicionadas com este comando.
• Se um node_modules já estiver presente, ele será removido automaticamente antes que o npm ci comece sua instalação.
• Nunca escreverá em package.json ou em qualquer um dos package-locks: as instalações estão essencialmente congeladas.