Composer sem mitos: manter as dependências PHP saudáveis
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 updateO 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.4significa 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.4significa 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.
Tens um site WordPress que não para de se partir? Vê o que faço e como trabalho.