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}
ounpm 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:
- Retornar o
package.json
e opackage-lock
para a versão antiga - Executar os comandos de
install
e/ouupdate
que foram feitos nos dois commits - Commitar a nova versão do
package-lock
epackage.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:
- 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.
- 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 libacorn
, o qual owebpack
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/