Confirmo o arquivo package-lock.json criado pelo npm 5?


1396

O npm 5 foi lançado hoje e um dos novos recursos inclui instalações determinísticas com a criação de um package-lock.jsonarquivo.

Esse arquivo deve ser mantido no controle de origem?

Eu estou assumindo que é semelhante ao yarn.locke composer.lock, ambos os quais devem ser mantidos em controle de origem.


20
Resposta curta: sim. Um comentário: quando o package-lock.json é alterado, você pode confirmar apenas essa alteração, separar-se de outras alterações de origem. Isso git logfacilita o manuseio.
Purplejacket

14
Um arquivo não pode ajudar a produzir uma instalação determinística se não existir.
Alan H.

4
Depende do projeto. github.com/npm/npm/issues/20603
Gajus

3
Se você realmente confia na NPM, o objetivo é relatar mais explicitamente o que o projeto está usando. Se você realmente deseja previsibilidade, ignore esse arquivo e, em vez disso, instale o node_modules (consulte .npmrc e a configuração relacionada nas respostas + comentário) e use-o para rastrear o que está realmente mudando, e não o que o gerenciador de pacotes afirma que está fazendo. Em última análise: o que é mais importante? Seu gerenciador de pacotes ou o código que você está usando.
Jimmont 30/11

Respostas:


1617

Sim, package-lock.jsondeve ser verificado no controle de origem. Se você estiver usando o npm 5, poderá ver isso na linha de comando: created a lockfile as package-lock.json. You should commit this file.De acordo com npm help package-lock.json:

package-lock.jsoné gerado automaticamente para qualquer operação em que o npm modifique a node_modulesárvore 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 intermediárias de dependência.

Este arquivo deve ser confirmado nos repositórios de origem e serve a vários propósitos:

  • Descreva uma única representação de uma árvore de dependência, de modo que colegas de equipe, implantações e integração contínua garantam a instalação exatamente das mesmas dependências.

  • Forneça um recurso para os usuários "viajarem no tempo" para estados anteriores node_modulessem precisar confirmar o próprio diretório.

  • Para facilitar uma maior visibilidade das alterações nas árvores por meio de diferenças de controle de fonte legíveis.

  • E otimize o processo de instalação, permitindo que o npm pule resoluções repetidas de metadados para pacotes instalados anteriormente.

Um detalhe importante package-lock.jsoné que ele não pode ser publicado e será ignorado se encontrado em outro local que não seja o pacote de nível superior. Ele compartilha um formato com o npm-shrinkwrap.json (5), que é essencialmente o mesmo arquivo, mas permite a publicação. Isso não é recomendado, a menos que você implemente uma ferramenta CLI ou use o processo de publicação para produzir pacotes de produção.

Se ambos package-lock.jsone npm-shrinkwrap.jsonestiverem presentes na raiz de um pacote, package-lock.jsonserão completamente ignorados.


77
Em que tipo de projetos é realmente útil confirmar o arquivo? O ponto principal de semver e package.json é que as dependências compatíveis atualizadas não precisam ser observadas.
Curiousdannii 27/05

45
A palavra-chave é "não deveria ser" - mas, na prática, as pessoas não seguem nem sempre perfeitamente. É por isso que você pode usar o package-lock.json e o package.json juntos para facilitar a atualização dos pacotes, mas ainda garantindo que todos os desenvolvedores e aplicativos implantados usem a mesma árvore de dependência.
Panu Horsmalahti

34
@trusktr: Sindre Sorhus recomenda usar "Lockfiles para aplicativos, mas não para pacotes".
vine77

23
Outra coisa é que o package-lock.json é ignorado para publicação no NPM; portanto, se um desenvolvedor o usa para um desenvolvedor de biblioteca, eles estão minimizando a chance de obter uma regressão de uma versão de dependência atualizada e, portanto, passarão bug para usuários finais. Por esse motivo, não usar um arquivo de bloqueio para a biblioteca dev aumenta a chance de enviar menos erros.
trusktr

128
Pessoalmente, agora tive que recorrer a adicionar package-lock.jsonao meu .gitignore... estava me causando muito mais problemas do que resolvê-los. Ele sempre entra em conflito quando mesclamos ou reestruturamos, e quando uma mesclagem resulta em uma package-lock.jsoncorrupção no servidor de IC, é apenas uma dor ter que ficar consertando-o.
Stefan Z Camilleri

111

Sim, o objetivo é fazer check-in. Quero sugerir que ele obtenha seu próprio commit exclusivo. Descobrimos que ele adiciona muito ruído às nossas diferenças.


19
é justo discutir se ele deve ser verificado no seu repositório de código-fonte, mas a publicação desse arquivo no npm não está realmente em debate - você deve incluir o arquivo package-lock.json ou o shrinkwrap no registro do npm. caso contrário, seu pacote publicado estará sujeito a alterações não dependentes de suas dependências de 1ª geração. você não perceberá que isso é um problema até que uma dessas dependências da 2ª geração publique uma alteração de quebra e seu pacote publicado se torne misteriosamente quebrado. este arquivo package-lock.json foi criado para resolver esse problema.
guerillapresident

9
@BetoAveiga by noise Quero dizer que as confirmações com package-lock.json podem ter tantas linhas de versões de pacotes de nós, que qualquer outro trabalho nessa confirmação fica oculto.
Xer0x

7
Normalmente, mantenho instalações de pacotes separadas de outros trabalhos. Eu nunca preciso diferenciar um commit como "Chai e mocha instalados", porque já sei o que mudou.
Keith

3
Algum conselho sobre o package-lock.jsonarquivo ao trabalhar em um sistema SCM com troncos e ramificações? Estou fazendo algumas alterações em um ramo que precisa ser mesclado ao tronco ... agora tenho que (de alguma forma) resolver conflitos entre os dois package-lock.jsonarquivos? Isso parece doloroso.
precisa saber é o seguinte

3
@guerillapresident Pelo que entendi, você está parcialmente correto. A publicação desse arquivo no npm não está em debate. Você não pode publicá-lo.
Tim Gautier

66

Sim você deveria:

  1. confirmar o package-lock.json.
  2. use em npm civez denpm install criar seus aplicativos no seu CI e na sua máquina de desenvolvimento local

O npm cifluxo de trabalho requer a existência de a package-lock.json.


Uma grande desvantagem do npm installcomando é seu comportamento inesperado, que pode sofrer alterações package-lock.json, enquanto npm ciapenas usa as versões especificadas no arquivo de bloqueio e produz um erro

  • se o package-lock.jsone package.jsonestiver fora de sincronia
  • se um package-lock.jsonestiver faltando.

Portanto, executando npm installlocalmente, esp. em equipes maiores com vários desenvolvedores, pode levar a muitos conflitos entre os package-lock.jsondesenvolvedores e decidirem excluir completamente o package-lock.jsonarquivo.

No entanto, existe um forte caso de uso para poder confiar que as dependências do projeto resolvem repetidamente de maneira confiável em diferentes máquinas.

De um, package-lock.jsonvocê obtém exatamente isso: um estado conhecido pelo trabalho.

No passado, eu tinha projetos sem arquivos package-lock.json/ npm-shrinkwrap.json/ yarn.lockcuja construção falharia um dia porque uma dependência aleatória recebeu uma atualização de última hora.

É difícil resolver esses problemas, pois às vezes você precisa adivinhar qual era a última versão de trabalho.

Se você deseja adicionar uma nova dependência, ainda executa npm install {dependency}. Se você deseja atualizar, use ou npm update {dependency}ou npm install ${dependendency}@{version}confirme a alteração package-lock.json.

Se uma atualização falhar, você poderá reverter para o último trabalho conhecido package-lock.json.


Para citar o npm doc :

É altamente recomendável que você comprometa o bloqueio do pacote gerado no controle de origem: isso permitirá que qualquer outra pessoa em sua equipe, suas implantações, seu IC / integração contínua e qualquer outra pessoa que execute a instalação do npm na sua fonte de pacotes obtenha exatamente a mesma árvore de dependência em que você estava desenvolvendo. Além disso, as diferenças dessas alterações são legíveis por humanos e o informarão sobre quaisquer alterações feitas pelo npm em seus node_modules, para que você possa observar se alguma dependência transitiva foi atualizada, içada, etc.

E no que diz respeito à diferença entre npm civsnpm install :

  • O projeto deve ter um pacote-lock.json ou npm-shrinkwrap.json existente.
  • Se as dependências no bloqueio do pacote não corresponderem às do package.json, npm cisairá com um erro, em vez de atualizar o bloqueio do pacote.
  • npm ci pode instalar projetos inteiros por vez: dependências individuais não podem ser adicionadas com este comando.
  • Se um node_modulesjá estiver presente, ele será removido automaticamente antes do npm ciinício da instalação.
  • Ele nunca gravará em package.jsonou nenhum dos bloqueios de pacotes: as instalações são essencialmente congeladas.

Nota: Eu publiquei uma resposta semelhante aqui


10
Essa resposta merece mais crédito, especialmente usando o npm ci. O uso disso reduz a maioria dos problemas que as pessoas enfrentaram com o bloqueio de pacotes.
21419

Eu descobri que usar a versão fixa no package.json (sem intercalação ou til) é uma opção muito mais limpa. Isso me salva do whose build would fail one day because a random dependency got a breaking updatetipo de problema. Embora deixe a possibilidade de dependência da criança, causando o mesmo problema.
Ashwani Agarwal

58

Sim, a melhor prática é fazer o check-in (SIM, CHECK-IN)

Concordo que causará muito barulho ou conflito ao ver o diff. Mas os benefícios são:

  1. garantir exatamente a mesma versão de cada pacote . Esta parte é a mais importante ao construir em ambientes diferentes em momentos diferentes. Você pode usar ^1.2.3no seu package.json, mas como você pode garantir que cada vez npm installescolha a mesma versão em sua máquina de desenvolvimento e no servidor de compilação, especialmente aqueles pacotes de dependência indireta? Bem, package-lock.jsongarantirá isso. (Com a ajuda de npm cique instala pacotes com base no arquivo de bloqueio)
  2. melhora o processo de instalação.
  3. ajuda com o novo recurso de auditoria npm audit fix(acho que o recurso de auditoria é da npm versão 6).

3
Até onde eu sei, nunca usar o semver (que os npm devs não entendem de qualquer maneira) deve gerar o mesmo comportamento de ter um arquivo de bloqueio pelo menos em 99% dos casos. Minha própria experiência é que sempre os fuckups acontecem principalmente com pacotes primários (dependências diretas, datas ruins de jquery, etc). Minha experiência pessoal com o npm foi que os arquivos de bloqueio eram barulho para sempre. Espero que essa sabedoria não seja alterada nas versões recentes.
Svend

13
+1 por mencionar npm ci. As pessoas freqüentemente mencionam que a package-lock.jsonpermite uma instalação determinística de pacotes, mas quase nunca menciona o comando que facilita esse comportamento! Muitas pessoas provavelmente supõem incorretamente npm installinstala exatamente o que está no arquivo de bloqueio ...
ahaurat

ci npm não está na npm 5.
dpurrington

Obrigado! Só faz sentido confirmar o package-lock.json se você estiver usando npm ci. Sua equipe / desenvolvedor líder pode decidir quando atualizar. Se todo mundo está cometendo isso arbitrariamente, não há motivo para isso, e isso está apenas criando ruído em seu repositório. A documentação do NPM deve deixar isso mais claro. Eu acho que a maioria dos desenvolvedores está confusa com esse recurso.
adampasz

@adampasz, na verdade, cada desenvolvedor pode confirmar o arquivo de bloqueio e, uma vez aprovado no teste e mesclado, o segundo ramo apenas renova o arquivo de bloqueio se, de alguma forma, os pacotes forem alterados (não mudamos o pacote.json frequentemente, estamos menos enfrentando esse problema (
Xin

38

Não comprometo este arquivo nos meus projetos. Qual é o objetivo?

  1. É gerado
  2. É a causa de um erro de integridade do código SHA1 no gitlab com as compilações gitlab-ci.yml

Embora seja verdade que eu nunca usei ^ no meu package.json para bibliotecas porque tive experiências ruins com ele.


11
Eu gostaria que isso pudesse ser exposto mais a partir dos documentos do npm - Seria útil ter um resumo do que especificamente você perde por não cometer package-lock.json. Algumas operações compromissadas podem não exigir os benefícios advindos da sua incorporação e podem preferir não ter conteúdo gerado automaticamente na fonte.
PotatoFarmer 01/10/1918

2
Eu posso ver como isso pode ser útil para depuração (uma diferença entre dois bloqueios, por exemplo) para ajudar a resolver problemas. Eu acho que também pode ser usado para evitar esse tipo de coisa, mas também pode ser uma dor tê-lo em um repositório compartilhado, onde pode ocorrer conflitos de mesclagem devido a ele. Para iniciantes, quero manter as coisas simples, vou usar o package.json por conta própria até ver uma necessidade real do package-lock.json.
Radtek 14/03/19

6
Você não pode usar ^ em seu package.json, mas pode ter certeza de que suas dependências não o usam?
Neiker 15/05/19

35

Para as pessoas reclamando do barulho ao fazer git diff:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

O que eu fiz foi usar um alias:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Para ignorar o package-lock.json no diffs para todo o repositório (todos os que o usam), você pode adicioná-lo ao .gitattributes :

package-lock.json binary
yarn.lock binary

Isso resultará em diferenças que mostram "Os arquivos binários a / package-lock.json eb / package-lock.json diferem sempre que o arquivo de bloqueio do pacote é alterado. Além disso, alguns serviços Git (principalmente o GitLab, mas não o GitHub) também excluem esses arquivos (não são mais de 10 mil linhas alteradas!) das diferenças ao exibir on-line ao fazer isso.


1
Eu tenho gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }no meu .bashrc em vez de um alias.
Apostl3pol 14/05/19

16

Sim, você pode confirmar este arquivo. Dos documentos oficiais da NPM :

package-lock.jsoné gerado automaticamente para qualquer operação em que npmmodifique a node_modulesárvore 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 intermediárias de dependência.

Este arquivo deve ser confirmado nos repositórios de origem [.]


13
Uma instalação não atualiza sempre node_modules e, portanto, atualiza o package-lock.json?
Tim Gautier

2
Não, você pode executar npm cia instalação a partir do package-lock.json
William Hampshire

Você precisa enfatizar em sua resposta que DEVE usar o npm ci em sua compilação de integração contínua se tiver o package-lock.json no
repositório

6

Desativar globalmente o package-lock.json

digite o seguinte em seu terminal:

npm config set package-lock false

isso realmente funciona para mim como mágica


2
isso cria ~/.npmrc(pelo menos no meu macos) com conteúdo package-lock=falsee o mesmo pode ser feito em qualquer projeto específico ao lado node_modules/(por exemploecho 'package-lock=false' >> .npmrc
jimmont 30/11/18

6
é engraçado para mim que isso seria negativo. a comunidade npm simplesmente não pode aceitar que a geração automática do package-lock.json tenha sido um envolvimento ruim da comunidade. você não deve fazer coisas que possam impactar o processo de uma equipe. deveria ter sido uma opção para ativar, não forçada. Quantas pessoas fazem "git add *" e nem percebem e estragam as construções. Se você tem algum tipo de fluxo baseado em mesclagem, eu sei que o fluxo git é como a Bíblia para as pessoas que o usam, isso não funcionará. você não pode ter geração em fusão! O versionamento do npm está quebrado, o pacote: 1.0.0 deve ser determinístico!
Eric Twilegar 5/02/19

3
por que isso é votado para baixo? essa é claramente uma maneira legítima de desativar um recurso que não funciona. E, embora não responda à pergunta em si, discute a questão. isto é, não precisa mais responder. Polegares para cima de mim :)
Superole 06/02

A razão pela qual a votação foi reduzida é porque você está simplesmente desativando um recurso.
Raza

5

Sim, é uma prática padrão confirmar o pacote-lock.json

O principal motivo para confirmar o pacote-lock.json é que todos no projeto estão na mesma versão do pacote.

Prós: -

  • Se você segue o controle de versão estrito e não permite que a atualização para as versões principais automaticamente se salve de alterações incompatíveis com versões anteriores em pacotes de terceiros que cometerem o bloqueio de pacotes, isso ajuda bastante.
  • Se você atualizar um pacote específico, ele será atualizado no package-lock.json e todos os usuários do repositório serão atualizados para essa versão específica quando receberem as alterações.

Contras: -

  • Pode fazer com que suas solicitações pull sejam feias :) '

Edit: - O npm install não garante que todos no projeto estejam na mesma versão do pacote. O npm ci ajudará com isso.


4
Os contras desapareceriam se você usasse em npm civez de npm install.
K0pernikus 06/09/19

2
Escopo rastejando um pouco, mas aqui estão mais informações sobre esses excelentes conselhos do @ k0pernikus .
Ruffin

1
"Todos no projeto estarão na mesma versão do pacote, tudo o que você precisa fazer é instalar o npm" Não é verdade, você precisa usar o "npm ci"
reggaeguitar

Obrigado, @reggaeguitar. Atualizando minha resposta para isso.
Nikhil Mohadikar 17/03

2

Meu uso do npm é gerar css / js minificado / uglificado e gerar o javascript necessário nas páginas atendidas por um aplicativo django. Nos meus aplicativos, o Javascript é executado na página para criar animações, às vezes executar chamadas ajax, trabalhar dentro de uma estrutura VUE e / ou trabalhar com o css. Se o package-lock.json tiver algum controle sobre o conteúdo do package.json, poderá ser necessário que exista uma versão desse arquivo. Na minha experiência, isso não afeta o que é instalado pelo npm install ou, se o fizer, não afetou de maneira adversa os aplicativos que implanto para o meu conhecimento. Eu não uso mongodb ou outros aplicativos que são tradicionalmente thin client.

Eu removo o package-lock.json do repo porque o npm install gera esse arquivo e o npm install faz parte do processo de implantação em cada servidor que executa o aplicativo. O controle de versão do nó e do npm é feito manualmente em cada servidor, mas tenho o cuidado de que eles sejam iguais.

Quando npm installé executado no servidor, ele altera o package-lock.json e, se houver alterações em um arquivo que é registrado pelo repositório no servidor, a próxima implantação WONT permitirá que você obtenha novas alterações da origem. Ou seja, você não pode implantar porque a solicitação substituirá as alterações feitas no package-lock.json.

Você não pode sobrescrever um package-lock.json gerado localmente pelo que está no repositório (redefinir o hard origin master), pois o npm reclamará sempre que você emitir um comando se o package-lock.json não refletir o que está em node_modules devido à instalação do npm, interrompendo a implementação. Agora, se isso indica que versões ligeiramente diferentes foram instaladas no node_modules, mais uma vez isso nunca me causou problemas.

Se node_modules não estiver no seu repositório (e não deveria estar), o package-lock.json deve ser ignorado.

Se estiver faltando alguma coisa, corrija-me nos comentários, mas o ponto em que o versionamento é retirado desse arquivo não faz sentido. O arquivo package.json possui números de versão, e presumo que esse arquivo seja o usado para criar pacotes quando a instalação do npm ocorre, como quando eu o removo, o npm install reclama da seguinte maneira:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

e a construção falhar, no entanto, ao instalar o node_modules ou ao aplicar o npm para construir o js / css, nenhuma reclamação será feita se eu remover o package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

Apenas para adicionar, agora comprometi meu package-lock.json no meu repositório e estou usando o npm ci na minha implementação ansível, que acredito que delete o node_modules, e instala tudo no package-lock.json sem atualizá-lo. Isso permite que o meu front-end atualize o material javascript sem a necessidade de intervenção manual na implantação.
MagicLAMP
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.