Skip to content

Instantly share code, notes, and snippets.

@adrianolobo
Last active February 2, 2023 07:31
Show Gist options
  • Save adrianolobo/9364c73f0abb20a81629580eb8f8bf0d to your computer and use it in GitHub Desktop.
Save adrianolobo/9364c73f0abb20a81629580eb8f8bf0d to your computer and use it in GitHub Desktop.
Guia para gerência de dependências npm/yarn

Gerência das dependências do projeto

As dependências do projeto estão listadas no arquivo package.json , elas estão organizadas em duas categorias:

  • dependencies: Dependências referente ao projeto em runtime. São dependências que serão executadas pelo browser do usuário. Exemplo: vue, axios, moment...
  • devDependencies: Dependências que suportam o desenvolvimento do projeto. Exemplo: webpack, babel, eslit...

Ao realizar uma instalação limpa das dependências (npm install) é gerado o arquivo package-lock.json, este json é responsável por garantir que as mesmas versões das dependências serão instaladas entre os ambientes, por este motivo ele deve ser commitado! Porém, apenas em 2 situações ele deverá ter modificações, são elas:

  • Quando uma nova dependência é adicionada no projeto (npm i --save {dep} ou npm i --save-dev {dep} )
  • Quando deseja-se ativamente atualizar as dependências do projeto (npm update)

Em nenhum outro momento deve-se gerar um novo package-lock.json, por isso o comando npm ci (disponível para versão do npm > 5.7.0) deve ser usado na grande maioria das vezes. Este comando instala todas as dependências a partir do package-lock, e não do package.json, garantindo assim as mesmas dependências entre ambientes e não alterando o package-lock no processo. Ele também gera erro caso exista uma diferença entre package.json e package-lock.json, isso garante a integridade da versão de produção. Com a utilização deste comando não deve-se mais fazer a prática de deletar o package-lock para realizar um clean install.

O que fazer caso haja conflito no package-lock?

Utilizando essas práticas os conflitos devem diminuir consideravelmente, mas caso haja, deve ser pois duas pessoas adicionaram uma dependência, ou duas pessoas atualizaram as versões do sistema de propósito, nestes casos, a pessoa que for resolver o conflito deve seguir os seguintes passos:

  1. Retornar o package.json e o package-lock para a versão antiga
  2. Executar os comandos de install e/ou update que foram feitos nos dois commits
  3. Commitar a nova versão do package-lock e package.json. Com este procedimento deve-se evitar ao máximo deletar o package-lock e criar de novo para resolver o conflito, caso não saiba o quê fazer, peça ajuda.

Por quê não devemos apenas remover o ^ das dependências, travando elas no próprio package.json?

Por dois motivos:

  1. Ao travar as versões no próprio package.json irá tornar o processo de atualização das dependências algo muito manual e demorado, pois sempre terá subir a versão manualmente e checar por compatibilidade entre as outras libs. A atualização das dependências é algo fundamental para o projeto já que disponibiliza novas features e corrige falhas, deixando esse processo custoso há grande chance de ser deixado de lado.
  2. Travando as versões apenas removendo o ^ não trava a versão da dependência da dependência, ou seja, se travar a versão do webpack removendo o ^, isso não garante que a versão da lib acorn, o qual o webpack depende, será travada, gerando assim uma falsa sensação de segurança. Apenas o package-lock consegue travar toda a árvore de dependências.

E quanto ao yarn?

Em vez do package-lock o yarn gera o yarn.lock, e o comando que substitui o npm ci é o yarn --frozen-lockfile

Fonte: https://medium.com/@Cyclodex/demystifying-npm-install-npm-ci-package-lock-json-2807fc0ee404 https://docs.npmjs.com/files/package-lock.json https://yarnpkg.com/lang/en/docs/yarn-lock/ https://yarnpkg.com/lang/en/docs/cli/install/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment