Composer vs npm: gerenciadores de dependências PHP e Node no CI
O Composer é o gerenciador de dependências do PHP e o npm é o do Node - muitos repositórios full-stack usam os dois, então a pergunta real é como cada um se comporta no CI.
O Composer gerencia dependências e autoloading do PHP a partir de um composer.json/composer.lock. O npm gerencia pacotes Node a partir de package.json/package-lock.json. Eles têm como alvo runtimes diferentes, mas compartilham o mesmo padrão de lockfile e cache.
| Composer | npm | |
|---|---|---|
| Ecossistema | PHP (Packagist) | JavaScript (registro npm) |
| Lockfile | composer.lock | package-lock.json |
| Instalação no CI | composer install --no-dev (prod) | npm ci |
| Autoloading | Geração de autoloader PSR-4 | Resolução de módulos (Node) |
| Reprodutibilidade | A partir do lock | A partir do lock |
No CI
Ambos querem um lockfile commitado e um comando de instalação determinístico: composer install (frequentemente com --no-dev --optimize-autoloader para produção) e npm ci. Um app full-stack costuma executar as duas etapas em um único job - dependências PHP via Composer, dependências de frontend via npm. Cada um é rápido quando seu cache está aquecido e lento em uma instalação a frio de muitos pacotes nativos ou pesados em autoload.
Faça cache dos dois
Faça cache do diretório vendor do Composer (com chave em composer.lock) e do node_modules/cache do npm (com chave em package-lock.json) separadamente. Ambas as instalações rodam em runners de CI; runners gerenciados mais rápidos encurtam a instalação a frio que dominar o tempo.
O veredito
Eles não são intercambiáveis - Composer para PHP, npm para Node. Em um pipeline full-stack você usa os dois: faça commit de cada lockfile, use o comando de instalação determinístico e faça cache do diretório de cada ecossistema de forma independente.