~ O Blog de 1999 ~

A maior parte da dor das dependências é auto-infligida

O Composer não é complicado. O que mete as equipas em sarilhos é um punhado de hábitos que parecem inofensivos até ao dia em que deixam de ser. Esta é a rotina que uso em todos os projetos.

O lock file pertence ao git

O composer.lock não é um artefacto de build. É o registo exato das versões contra as quais a tua aplicação foi testada. Faz commit dele e nunca deixes um servidor gerá-lo. Se dois programadores correm versões diferentes da mesma biblioteca, não tens um build reprodutível, tens um lançamento de moeda ao ar.

Install nos servidores, update na tua máquina

Esta é a regra que evita a maioria das surpresas.

# no servidor, em deployment
composer install --no-dev --optimize-autoloader

# na tua máquina, quando queres mesmo mexer em versões
composer update

O composer install lê o lock file e dá-te exatamente o que lá está. O composer update vai procurar versões mais recentes e reescreve o lock file. Correr update num servidor significa que cada deployment é um pequeno upgrade não planeado.

Lê as restrições que escreves

O circunflexo e o til parecem-se e comportam-se de maneira diferente.

• ^1.4 significa qualquer versão a partir de 1.4 até, sem incluir, 2.0. Só deixas entrar alterações que quebram quando atravessas a fronteira da versão major.
• ~1.4 significa 1.4 e apenas as correções de 1.4. Mais apertado, e muitas vezes o que queres para uma biblioteca em que não queres pensar.
• 1.4.* significa apenas patches, a mais apertada das três.

Na maior parte dos casos o ^ está certo. O erro é não escolher. Deixar um wildcard onde tiveste demasiado ocupado para decidir é como acabas com um ticket de suporte numa terça-feira.

Atualiza em passos pequenos, de propósito

Atualizar vinte pacotes de uma vez e depois depurar é o caminho lento. Atualiza um grupo, corre os testes, faz commit. Se algo rebentar, sabes exatamente qual foi o grupo. A atualização pequena semanal sai muito mais barata do que a emergência anual.

Fixa a tua plataforma

Se a produção corre PHP 8.3, escreve isso no ficheiro do composer. Caso contrário, a tua máquina, que corre algo mais recente, vai resolver alegremente um pacote que a produção não consegue instalar.

"config": {
    "platform": {
        "php": "8.3.0"
    }
}

Corre a auditoria

O composer audit verifica as tuas dependências contra bases de dados de vulnerabilidades conhecidas e diz-te quais têm avisos. É um comando, leva segundos e quase ninguém o corre. Mete-o na tua rotina, ou no CI, e ficas a saber de um pacote vulnerável por um relatório em vez de por um incidente.

A conclusão aborrecida

As dependências devem ser monótonas. Faz commit do lock file, usa install nos servidores, atualiza de propósito em lotes pequenos, fixa a versão de PHP e corre a auditoria uma vez por mês. É a rotina toda. O resto é preferência.