5 commandes Composer que vous n'utilisez pas (et devriez)

Tu connais composer require, composer install et composer update. Mais Composer embarque des commandes bien plus puissantes que la plupart des développeurs PHP ignorent. En voici cinq qui vont changer ta façon de gérer tes dépendances.

1. composer why — Pourquoi cette dépendance est-elle là ?

Tu tombes sur un package dans ton vendor/ et tu ne sais pas pourquoi il est installé ? composer why (alias depends) te montre la chaîne de dépendances.

$ composer why psr/log
monolog/monolog  3.5.0  requires  psr/log (^2.0 || ^3.0)
symfony/monolog-bundle  3.10.0  requires  psr/log (^2.0 || ^3.0)

Très utile avant de supprimer un package : tu vérifies d’abord que rien n’en dépend directement.

2. composer why-not — Pourquoi je ne peux pas monter de version ?

Tu veux passer à la dernière version d’un package mais composer update refuse ? composer why-not (alias prohibits) t’explique quel package bloque la mise à jour.

$ composer why-not symfony/console 7.0
symfony/framework-bundle  6.4.8  requires  symfony/console (^5.4 || ^6.0)
app/my-project            dev-main  requires  symfony/framework-bundle (^6.4)

Au lieu de deviner pourquoi la résolution échoue, tu vois immédiatement la contrainte bloquante. Indispensable lors des migrations Symfony.

3. composer audit — Vérifie les vulnérabilités connues

Depuis Composer 2.4, la commande audit vérifie tes dépendances contre la base de données Packagist des CVE connues. Depuis Composer 2.9, l’audit est même exécuté automatiquement après chaque install et update.

$ composer audit
Found 2 security vulnerability advisories affecting 2 packages:
+-------------------+--------------------------+
| Package           | CVE                      |
+-------------------+--------------------------+
| guzzlehttp/guzzle | CVE-2023-29197           |
| twig/twig         | CVE-2024-12345           |
+-------------------+--------------------------+

Intègre cette commande dans ta CI avec composer audit --format=json pour bloquer les merges en cas de vulnérabilité critique.

4. composer outdated --direct — Les mises à jour qui t’importent

La commande composer outdated sans option affiche toutes les dépendances obsolètes, y compris les transitives. Le flag --direct filtre uniquement tes dépendances explicites (celles de ton require et require-dev).

$ composer outdated --direct
Direct dependencies required in composer.json:
symfony/framework-bundle  6.4.8   7.1.3   Latest LTS available
phpstan/phpstan           1.10.50 1.12.4  Minor update available
phpunit/phpunit           10.5.8  11.3.1  Major update available

Le code couleur aide à prioriser : rouge = mise à jour majeure, jaune = mineure, vert = patch. Lance cette commande chaque semaine pour garder tes dépendances fraîches.

5. composer bump — Aligne les contraintes sur les versions installées

Depuis Composer 2.6, composer bump met à jour les contraintes de version dans ton composer.json pour qu’elles reflètent les versions minimales réellement installées.

# Avant bump :
"require": {
    "symfony/console": "^6.0"
}

$ composer bump

# Après bump :
"require": {
    "symfony/console": "^6.4.8"
}

L’intérêt ? Si tu distribues un package, tes utilisateurs n’installeront pas accidentellement une version ancienne incompatible. Et pour un projet, c’est une documentation explicite de ce qui a été testé.

Bonus : intègre-les dans ton workflow

Ces cinq commandes prennent toute leur valeur quand elles sont intégrées dans ta routine et ta CI :

• composer audit dans la CI pour bloquer les vulnérabilités
• composer outdated --direct en cron hebdomadaire
• composer why-not avant chaque tentative de migration
• composer bump avant chaque release de package
• composer why avant chaque suppression de dépendance

Composer est bien plus qu’un gestionnaire de packages : c’est un outil de diagnostic complet pour la santé de ton projet. Apprends à utiliser tout son potentiel.