Versionar ou não o composer.lock?
Muitos desenvolvedores ignoram o composer.lock via .gitignore na raiz do projeto, por esse ser uma arquivo gerado automaticamente. Analisando o principal propósito do arquivo, fazer isso não está errado, no entanto, é uma boa prática versionar seu composer.lock, então usar o comando composer install para preparar seu ambiente ao invés de composer update, você pode conferir aqui algumas bases sobre essa ideia para começar a aplicar em seus projetos.
- Você pode encontrar a Documentação do Composer dizendo:
"Você deve comitar o composer.lock no repositório do seu projeto para que todas as pessas trabalhando no projeto estejam usando as mesmas versões de dependências dos pacotes."
- Ter o composer.lock no projeto, faz a instalação via composer ser 2x mais rápida.
- Você pode deixar a instalação via Composer ainda mais otimizada utilizando os parametros para otimizar o autoload, preferir os pacotes via source e não intalar as dependências de desenvolvimento no ambiente de produção.
- Versionando o composer.lock cada desenvolvedor que instalar o projeto vai ter a mesma versão, evitando assim a framosa frase "Na minha máquina funciona!".
- Essa prática apenas não é recomendada para bibliotecas de acordo com a documentação do Composer.
- Nunca use o Composer update em produção, isso pode atualizar pacotes lá que não estejam atualizados no ambiente de teste, sendo assim por que existiria nosso ambiente de testes se ele estiver diferente.
Você já versionava seu composer.lock ou vai começar? Me fale nos comentários!