Por que o “npm install” reescreve o package-lock.json?

Recentemente, atualizei para npm @ 5 . Agora tenho um arquivo package-lock.json com tudo, desde package.json . Eu esperava que, ao executar, npm installas versões de dependência fossem extraídas do arquivo de bloqueio para determinar o que deveria ser instalado no meu diretório node_modules . O estranho é que ele acaba modificando e reescrevendo meu arquivo package-lock.json .

Por exemplo, o arquivo de bloqueio tinha o texto datilografado especificado para a versão 2.1.6 . Depois do npm installcomando, a versão foi alterada para 2.4.1 . Isso parece derrotar todo o objetivo de um arquivo de bloqueio.

o que estou perdendo? Como faço para que o npm respeite meu arquivo de bloqueio?

Atualização 3: Como outras respostas também apontam, o npm cicomando foi introduzido na npm 5.7.0 como forma adicional de obter compilações rápidas e reproduzíveis no contexto do IC. Consulte a documentação e o blog do npm para obter mais informações.

Atualização 2: O problema para atualizar e esclarecer a documentação é o problema no GitHub # 18103 .

Atualização 1: O comportamento descrito abaixo foi corrigido na npm 5.4.2: o comportamento pretendido atualmente é descrito na edição # 17979 do GitHub .

Resposta original: o comportamento de package-lock.jsonfoi alterado na npm 5.1.0, conforme discutido na edição # 16866 . O comportamento que você observa é aparentemente planejado pelo npm a partir da versão 5.1.0.

Isso significa que package.jsonpode substituir package-lock.jsonsempre que uma versão mais recente for encontrada para uma dependência no package.json. Se você deseja fixar suas dependências efetivamente, agora deve especificar as versões sem um prefixo; por exemplo, você precisa escrevê-las como em 1.2.0vez de ~1.2.0ou ^1.2.0. Em seguida, a combinação de package.jsone package-lock.jsonproduzirá construções reproduzíveis. Para ficar claro: package-lock.jsonsozinho já não bloqueia as dependências no nível raiz!

Se essa decisão de projeto foi boa ou não, é discutível, há uma discussão em andamento resultante dessa confusão no GitHub na edição # 17979 . (Aos meus olhos, é uma decisão questionável; pelo menos o nome locknão se aplica mais.)

Mais uma observação: há também uma restrição para registros que não suportam pacotes imutáveis, como quando você extrai pacotes diretamente do GitHub em vez de npmjs.org. Consulte esta documentação dos bloqueios de pacotes para obter mais explicações.

Eu descobri que haverá uma nova versão do npm 5.7.1 com o novo comando npm ci, que será instalado package-lock.jsonapenas

O novo comando npm ci é instalado somente a partir do seu arquivo de bloqueio. Se seu package.json e seu arquivo de bloqueio estiverem fora de sincronia, ele reportará um erro.

Ele funciona jogando fora o node_modules e recriando-o do zero.

Além de garantir que você obterá apenas o que está no seu arquivo de bloqueio, também é muito mais rápido (2x-10x!) Que a instalação do npm quando você não inicia com um node_modules.

Como você pode imaginar, esperamos que seja um grande benefício para ambientes de integração contínua. Também esperamos que as pessoas que fazem implantações de produção com tags git tenham grandes ganhos.

Use o recém-introduzido

npm ci

O npm ci promete o maior benefício para grandes equipes. Oferecer aos desenvolvedores a capacidade de "assinar" em um bloqueio de pacote promove uma colaboração mais eficiente entre grandes equipes, e a capacidade de instalar exatamente o que está em um arquivo de bloqueio tem o potencial de economizar dezenas, senão centenas de horas de desenvolvedor por mês, liberando equipes para gastar mais tempo construindo e enviando coisas incríveis.

Apresentando construções npm cimais rápidas e confiáveis

Resposta curta:

• npm install honra o package-lock.json apenas se atender aos requisitos do package.json.
• Se não atender a esses requisitos, os pacotes serão atualizados e o bloqueio do pacote será substituído.
• Se você preferir falhar na compilação, do que reescrever o bloqueio de pacotes quando isso acontecer, use npm ci.

Aqui está um cenário que pode explicar as coisas (verificado com o NPM 6.3.0)

Você declara uma dependência no package.json como:

"depA": "^1.0.0"

Então você faz, o npm installque irá gerar um package-lock.json com:

"depA": "1.0.0"

Poucos dias depois, uma versão menor mais nova de "depA" é lançada, diga "1.1.0", e o seguinte é verdadeiro:

npm ci       # respects only package-lock.json and installs 1.0.0

npm install  # also, respects the package-lock version and keeps 1.0.0 installed 
             # (i.e. when package-lock.json exists, it overrules package.json)

Em seguida, você atualiza manualmente o seu package.json para:

"depA": "^1.1.0"

Em seguida, execute novamente:

npm ci      # will try to honor package-lock which says 1.0.0
            # but that does not satisfy package.json requirement of "^1.1.0" 
            # so it would throw an error 

npm install # installs "1.1.0" (as required by the updated package.json)
            # also rewrites package-lock.json version to "1.1.0"
            # (i.e. when package.json is modified, it overrules the package-lock.json)

Use o npm cicomando em vez denpm install .

"ci" significa "integração contínua".

Ele instalará as dependências do projeto com base no arquivo package-lock.json, em vez das dependências do arquivo package.json.

Produzirá versões idênticas às de seus companheiros de equipe e também será muito mais rápido.

Você pode ler mais sobre isso nesta postagem do blog: https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

No futuro, você poderá usar um --from-lock-filesinalizador (ou similar) para instalar somente a partir do package-lock.jsonsem modificá-lo.

Isso será útil para ambientes de CI, etc. em que construções reproduzíveis são importantes.

Consulte https://github.com/npm/npm/issues/18286 para rastrear o recurso.

Parece que esse problema foi corrigido na npm v5.4.2

https://github.com/npm/npm/issues/17979

(Role para baixo até o último comentário no tópico)

Atualizar

Realmente corrigido em 5.6.0. Houve um erro de plataforma cruzada na 5.4.2 que estava causando o problema ainda ocorria.

https://github.com/npm/npm/issues/18712

Atualização 2

Veja minha resposta aqui: https://stackoverflow.com/a/53680257/1611058

npm ci é o comando que você deve usar ao instalar projetos existentes agora.

Você provavelmente tem algo como:

"typescript":"~2.1.6"

no package.jsonqual npm é atualizado para a versão secundária mais recente, no seu caso2.4.1

Edit: Pergunta do OP

Mas isso não explica por que "npm install" alteraria o arquivo de bloqueio. O arquivo de bloqueio não serve para criar uma compilação reproduzível? Nesse caso, independentemente do valor semver, ele ainda deve usar a mesma versão 2.1.6.

Responda:

Isso tem como objetivo bloquear sua árvore de dependência completa. Digamos que typescript v2.4.1requer widget ~v1.0.0. Quando você instala, ele pega widget v1.0.0. Posteriormente, seu colega desenvolvedor (ou compilação de IC) instala e obtém o npm, typescript v2.4.1mas widgetfoi atualizado para widget v1.0.1. Agora o seu módulo do nó está fora de sincronia. Isto é o que package-lock.jsonimpede.

Ou mais geralmente:

Como exemplo, considere

pacote A:

{"nome": "A", "versão": "0.1.0", "dependências": {"B": "<0.1.0"}}

pacote B:

{"nome": "B", "versão": "0.0.1", "dependências": {"C": "<0.1.0"}}

e pacote C:

{"nome": "C", "versão": "0.0.1"}

Se estas são as únicas versões de A, B e C disponíveis no registro, uma instalação normal do npm A instalará:

A@0.1.0 - B@0.0.1 - C@0.0.1

No entanto, se B@0.0.2 for publicado, uma nova instalação do NPM A será instalada:

A@0.1.0 - B@0.0.2 - C@0.0.1 assumindo que a nova versão não modificou as dependências de B. Obviamente, a nova versão do B pode incluir uma nova versão do C e qualquer número de novas dependências. Se tais alterações forem indesejáveis, o autor de A poderá especificar uma dependência em B@0.0.1. No entanto, se o autor de A e o autor de B não são a mesma pessoa, não há como o autor de A dizer que ele ou ela não deseja obter versões recém-publicadas de C quando B não mudou.

OP Pergunta 2: Então, deixe-me ver se entendi corretamente. O que você está dizendo é que o arquivo de bloqueio especifica as versões das dependências secundárias, mas ainda depende da correspondência difusa do package.json para determinar as dependências de nível superior. Isso é preciso?

Resposta: Não. Package-lock bloqueia toda a árvore de pacotes, incluindo os pacotes raiz descritos em package.json. Se typescriptestiver bloqueado no 2.4.1seu package-lock.json, ele deve permanecer assim até que seja alterado. E digamos que amanhã typescriptlibere a versão 2.4.2. Se eu fizer o checkout do seu ramo e executar npm install, o npm respeitará o arquivo de bloqueio e a instalação 2.4.1.

Mais sobre package-lock.json :

O package-lock.json é gerado automaticamente para qualquer operação em que o npm modifique a árvore node_modules ou o package.json. Ele descreve a árvore exata que foi gerada, de forma que as instalações subseqüentes 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 de node_modules sem 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.

https://docs.npmjs.com/files/package-lock.json

Provavelmente você deve usar algo como isto

npm ci

Ao invés de usar npm install se você não quiser alterar a versão do seu pacote.

De acordo com a documentação oficial, ambos npm installe npm ciinstalar as dependências que são necessários para o projeto.

A principal diferença é npm installque instala os pacotes tomando packge.jsoncomo referência. Onde, no caso de npm ci, ele instala os pacotes tomando package-lock.jsoncomo referência, certificando-se sempre que o pacote exato é instalado.

Existe um problema em aberto na página do github: https://github.com/npm/npm/issues/18712

Esse problema é mais grave quando os desenvolvedores estão usando diferentes sistemas operacionais.

EDIT: o nome "lock" é complicado, seu NPM está tentando atualizar o Yarn. Não é um arquivo bloqueado. package.jsoné um arquivo fixo pelo usuário que, uma vez "instalado", gerará a árvore de pastas node_modules e a árvore será gravada package-lock.json. Então, veja bem, é o contrário - as versões de dependência serão retiradas package.jsoncomo sempre e package-lock.jsondevem ser chamadaspackage-tree.json

(espero que isso tenha esclarecido minha resposta depois de tantos votos negativos)

Uma resposta simplista: package.jsontenha suas dependências como de costume, enquanto package-lock.jsoné "uma árvore node_modules exata e mais importante, reproduzível" (extraída do próprio npm docs ).

Quanto ao nome complicado, seu NPM está tentando alcançar Yarn.