Executando verificação de segurança...
1

Enviar ou não o arquivo de lock de um projeto JavaScript ao repositório remoto?

Fala pessoal, tudo certinho?

Recentemente causei um pequeno dabate em meu time sobre este cenário de enviar ou não nosso arquivo de lock (package-lock.json, pnpm-lock.yml, etc) ao repositório da aplicação.

Eu pessoalmente nunca liguei para esse questionamento, mas vi em alguns fóruns que esse debate existe, e que tem vantagens e desvantagens em manter um arquivo de lock num repositório.

Pessoalmente, pra vocês, como é feito no dia a dia? Realmente veem algum problema em não ignorar o envio do arquivo? Todos na equipe utilizam o mesmo gerenciador de pacotes? Gostaria de saber a opinião de vocês

Carregando publicação patrocinada...
3

A resposta curta: sim

A resposta longa:

A finalidade deste arquivo é garantir a consistência e a reprodutibilidade das dependências em projetos que usam JavaScript.

Ele registra a versão exata de cada pacote e suas dependências, e isso garante que, ao instalar o projeto em diferentes ambientes ou por diferentes desenvolvedores, todos utilizem as mesmas versões.

Além disso, o arquivo ajuda a acelerar o processo de instalação de dependências, pois o npm não precisa resolver versões ao instalar, utilizando as informações já definidas no package-lock.json.

Havendo alterações nas dependências (como adicionar ou remover pacotes), o package-lock.json é atualizado automaticamente. Isso permite que outros desenvolvedores se beneficiem das mesmas exatas mudanças.

É essencial para manter a integridade e a previsibilidade das dependências em um projeto JS. Sem ele, por exemplo, você pode ter uma versão instalada de um pacote, e outro desenvolvedor pode ter outra versão, o que pode causar bugs inesperados e difíceis de serem identificados, pois às vezes muda apenas o último número da versão.

Exemplo: Um desenvolvedor instala [email protected] e outro instala [email protected], e o package-lock.json impediria que isso acontecesse.

2
1

também penso assim. mas já tive problemas em equipe pois cada um tinha um sistema diferente pra trabalhar.
Linux, Windows e Mac OS
então sempre tinha algum bug ou erro ao tentar instalar as dependências que usam de binários ou comandos específicos pra cada sistema
ocasionando na constante regravação do lock (gerando risco de o deploy no servidor quebrar)

1
1

usamos docker e mesmo assim isso acontece.
não da pra usar docker 100% do tempo pra desenvolvimento. cada modificação minima fazer deploy de uma nova imagem? cansativo.
então eu fico encarregado de "ajustar" pro docker. pessoal sobe suas modificações com seus arquivos lock distintos e eu testo se ta construindo a imagem corretamente.
Docker ajuda sim, sou super fã. Mas tem detalhes que nem o docker "tanka".