# Versionar ou não versionar o composer.lock

> Há um bom tempo atrás, debati com um colega de trabalho sobre a necessidade de se versionar o arquivo composer.lock. Na época, tivemos boas...

- URL: https://iagofrota.com.br/blog/versionar-ou-nao-versionar-o-composer-lock/
- Data: 2020-05-14
- Tags: composer, git, gitignore, projeto-pessoal

Há um bom tempo atrás, debati com um colega de trabalho sobre a necessidade de se versionar o arquivo _composer.lock_. Na época, tivemos boas discussões referente a isso, então resolvi criar um artigo explicando sobre o que é e a necessidade de se versionar o arquivo _composer.lock._

![Executando o comando composer install](https://media-exp1.licdn.com/dms/image/C4E12AQELyJjGL9cNOw/article-inline_image-shrink_1000_1488/0?e=1594857600&v=beta&t=k3JzlDjk-G3AGU673NEo5cQW7vCDsXIBdVkdJVs9IzY)

## Introdução

O arquivo _composer.lock_, será criado, caso ele não exista, quando executamos o comando

```
composer install
```

Nele terá os pacotes e versões definidos no arquivo _composer.json_, inclusive, toda a as dependências dos pacotes que foram baixados.

Por fim, no arquivo _composer.lock_, terá toda a hierarquia de pacotes e dependências dos pacotes com as suas versões "bloqueadas".

## Motivações e Vantagens

Acredito que com a introdução, você já deve ter adiantado a vantagem de todo o time do projeto baixar os pacotes nas mesmas versões. Mas não é só isso!

Além de garantir de que todo time irá trabalhar utilizando as mesmas versões dos pacotes e suas dependências, você terá uma maior rapidez na instalação desses pacotes, por que o Composer não irá precisar ficar tentando descobrir qual versão de tal pacote ou dependência deverá ser instalado. Tudo já está lá no _composer.lock_.

## Conselho

Não é uma boa prática executar o comando _composer update_ sem um bom motivo. A explicação para isso seria que você irá atualizar todos os pacotes. Isso poderá atualizar algum pacote para um versão quebrada. Logo, acredito que o recomendado seria apenas executar o comando _composer install_. Irei explicar melhor a seguir.

### 1\. Executar o composer install quando não existe o composer.lock

Executando esse comando, você irá baixar os pacotes definidos no arquivo _composer.json_, com isso as dependências, e por fim, será gerado o _composer.lock_ com os pacotes nas versões definidas no _composer.json_.

### 2\. Executar o comando composer install quando existe o composer.lock

Fazendo isso, o Composer irá consulta o _composer.lock_ e baixar exatamente as versões dos pacotes e dependências definidas lá. Aqui, os pacotes será baixados em um velocidade maior, devido as versões das dependências já estarem definidas.

### 3\. Executar o comando composer update

Com esse comando, você irá atualizar todos os pacotes e dependências para uma versão superior a atual. Caso você não tenha deixado a versão dos pacotes estática, claro. Fazer isso não é interessante, pois você poderá atualizar um de seus pacotes para uma versão com problemas. Nessa situação, o _composer.lock_ será atualizado por completo.

Mas aí você me pergunta: "E seu eu quiser atualizar um certo pacote?". Simples. Execute o comando _composer update \[pacote\]_.

Exemplo:

```
composer update firebase/php-jwt
```

Com isso, você irá atualizar somente esse pacote e o composer.lock será atualizado pontualmente.

> Executar o comando **composer install** é seguro, pois ele irá adicionar somente o que foi definido no composer.json

> Executar o comando **composer update**, sem definir o pacote, não é tão seguro assim, pois ele irá atualizar a versão de todos os pacotes e dependências automáticamente

## Conclusão

Por fim, será muito interessante você versionar o arquivo _composer.lock_ e deixar a pasta _/vendor_ no _.gitignore_. Além de considerar, sempre, utilizar o _composer install_ em vez do _composer update_.

Espero que eu tenha sido claro sobre as motivações e vantagens em versionar o _composer.lock_. Espero, também, que os conselhos tenham sido úteis.

Obrigado!