a maioria dos serviços e aplicações modernos têm uma massa de dependências que vivem numa pasta cada vez maior node-modules. Em geral, muitas dessas bibliotecas estão sendo ativamente mantidas, alteradas e atualizadas. Se suas dependências são mal gerenciadas, você pode rapidamente encontrar-se no inferno de dependência.

se você não está familiarizado com npm, confira aqui antes de ler em

🛒 Mercearia Shopping

ao iniciar uma aplicação de nó, um dos primeiros passos está em execução npm install. Quando executar isto, o node irá verificar um ficheiro chamado package.json na base do seu projecto. Se esse arquivo for encontrado, ele vai usar a seção dependency como uma espécie de “Lista de compras de mercearia” para ir e reunir “ingredientes” (bits de código) que sua aplicação requer.

the “Mercearia” in this case is something npm calls a registry. Por padrão, seu aplicativo de nó irá procurar no registro público npm para esses pacotes, onde a maioria de tudo que você precisa será (registros privados podem ser criados para código proprietário e outros). Se o pacote for encontrado no registro, node coloca esse “ingrediente” em um diretório node_modules na base de seu projeto.

é importante notar que os pacotes de que necessita podem ter a sua própria “lista de compras” (pacote.json), e todas essas dependências aninhadas devem ser resolvidas antes que seu aplicativo se mova para a próxima dependência em seu próprio pacote.json.

⬆️ Versions, 🥕 Carets, and 🃏 Wildcards

the versions of your dependencies are generally something like v1.3.5. Isto é chamado de versionamento semântico, ou semver. Com a semver, os números representam alterações ao código em gravidade variável- MAJOR.MINOR.PATCH.
dos seus documentos –

versão principal quando você faz alterações de API incompatíveis,
versão menor quando você adiciona funcionalidade de uma maneira compatível para trás, e
versão PATCH quando você faz correções de bugs compatíveis para trás.

com isto em mente, muitas pessoas querem atualizar automaticamente o seu aplicativo com qualquer coisa nova que suas dependências possam ter em mudanças novas e não quebráveis.

prefixo com tilde ~ dar-lhe-á quaisquer novas actualizações PATCH, mas não maiores ou menores. Assim, ~1.3.1 poderia instalar 1.3.9, mas não 1.4.0

prefixo com cuidado ^ irá dar – lhe qualquer nova versão PATCH e MINOR, mas não maior. Portanto, ^1.3.1 poderia instalar 1.4.9 mas não 1.5.0
Alt Texto

Vamos dar uma olhada no nosso código de exemplo da árvore de dependência:

my-breakfast | | milk | |coffee-script 

Ok, mais como um pau, mas espero que a cadeia de dependência é claro. O nosso pacote.json está exigindo versão v0.5.0 especificamente de milk, mas o leite está requerendo coffee-script em qualquer lugar de 0.9.6 – 1.0.0. npm install é executado, desenvolvemos o nosso aplicativo, tudo é hunky-dory.

📼 agora vamos avançar 2 meses. Alguém encontra o teu projecto e quer contribuir. Eles bifurcam e clonam o teu repo, executam npm install, aaaae não funciona. “Mas funcionou na minha máquina!”tu choras. Quando seu colaborador instalou os módulos do nó, eles foram garantidos Uma versão específica de milk, mas eles receberam uma versão diferente de coffee-script porque o pacote de milk.o json usou o semver.

🗿 definir as suas dependências em pedra

uma solução para isto é usar um ficheiro package-lock.json. Este ficheiro dá-lhe um controlo muito granular sobre as versões de todas as dependências que instalar. Se o seu package.json é como a lista de compras, então o seu package-lock.json é como um orçamento. Podes comer cereais, mas vai ser uma marca de loja em vez de Cap’n Crunch. Esta especificidade percorre todos os ramos da sua árvore de dependências. Você deve ter um package.json se você quiser usar um arquivo de bloqueio (o package.json faz muito mais do que apenas gestão de dependências, que é apenas o foco deste post).

🎁 encerrar

pessoalmente sinto que um arquivo package-lock.json deve ser sempre usado (em versões mais recentes do npm, ele é realmente gerado automaticamente). Só torna tudo mais confiável entre ambientes e destacamentos. Aqui estão algumas últimas pepitas para ajudar quando se trata de dependecies:

• npm install --save irá atualizar automaticamente o seu lockfile e pacote.o json com o pacote.
• npm ci em vez de apenas npm install irá reconstruir automaticamente os módulos do seu nó, e construir a partir do seu lockfile. É um comando realmente útil para CI / CD e geralmente melhor para usar em conjunto com um lockfile.
• para projetos maiores, e dependência super robusta, check out docker e containers. Ele pode funcionar quase como uma máquina virtual que contém perfeitamente o seu código e suas dependências, e é clonado para promover a diferentes ambientes. Espero que acabes com muito menos problemas do tipo “funcionou na minha máquina”.