composer update --dry-run : cette simple commande, lancée sur un projet Bedrock qui n’a pas vu de mise à jour depuis deux ans, suffit à faire remonter des dizaines d’avertissements. Composer 2.7, sorti fin février 2024, change la façon dont l’outil résout les contraintes de version, et un vieux composer.json hérité d’une autre époque révèle soudain ses approximations.
La tentation, face à un projet qu’on n’ose plus toucher, est de reporter indéfiniment la mise à jour de Composer lui-même. Mauvaise idée : les images Docker et les environnements d’hébergement embarquent progressivement les nouvelles versions, et le décalage entre l’outil local et celui de la CI finit par produire des lockfiles incohérents.
Ce qui change concrètement en 2.7
Composer 2.7 introduit une résolution des contraintes plus prévisible : les alias de version implicites, tolérés dans les versions précédentes, sont désormais signalés. Sur un Bedrock ancien, cela touche en priorité les dépendances déclarées avec des contraintes larges comme * ou des branches de développement (dev-master) jamais nettoyées.
Autre changement notable : la commande composer why-not devient plus fiable pour comprendre pourquoi une extension refuse de monter de version, ce qui est précieux quand le projet mélange des extensions premium installées via Satis et des paquets WordPress.org via WPackagist.
Auditer sans rien casser
Avant toute modification, l’audit se fait sans écrire quoi que ce soit sur le disque :
composer update --dry-run --with-all-dependencies
composer outdated --direct
composer why-not roots/wordpress 6.5.0Cette séquence donne trois informations distinctes : ce qui bougerait si on lançait la mise à jour, ce qui est réellement obsolète parmi les dépendances directes, et ce qui bloque une montée de version précise. Sur un projet Bedrock de plusieurs années, il n’est pas rare de découvrir qu’une extension premium fixée en dur ("my-plugin/pro": "3.2.1") verrouille tout le reste.
Les pièges classiques d’un composer.json ancien
- Des contraintes en
*laissées après un import rapide, qui empêchent Composer de comprendre l’intention réelle de version. - Un
minimum-stabilityréglé surdevpour débloquer un paquet ponctuel, jamais revenu àstable. - Des dépôts Satis dont le token d’authentification a expiré sans que personne ne s’en aperçoive, faute d’exécuter Composer régulièrement.
- Un fichier
composer.lockcommitté pour une version de PHP qui n’est plus celle du serveur de production.
Un plan de mise à jour en trois passes
Plutôt que de tout mettre à jour d’un coup, une approche par passes limite le risque de régression :
- Mettre à jour Composer lui-même (
composer self-update) sans toucher aux dépendances du projet, et relancer une installation complète pour vérifier qu’elle passe. - Corriger les contraintes ambiguës une par une, en commençant par les extensions maison, plus faciles à tester que les extensions premium.
- Isoler la montée de version de Bedrock et de WordPress dans une passe séparée, avec sa propre revue de changelog.
Chaque passe donne lieu à un déploiement distinct sur un environnement de recette, avec les tests fonctionnels habituels du projet avant toute mise en production.
Ce qu’on gagne à ne pas attendre
Un composer.json propre se lit en trente secondes ; un composer.json hérité se déchiffre en une demi-journée. La différence de coût se paie une seule fois, mais elle se paie toujours.
Sur nos projets, revenir à des contraintes explicites (^6.5 plutôt que *) a réduit de moitié le temps passé à comprendre pourquoi une mise à jour bloquait. Ce n’est pas qu’un confort : c’est aussi ce qui permet de réagir vite quand une faille de sécurité impose une montée de version en urgence.
En résumé
Composer 2.7 ne casse rien par lui-même, mais il met en lumière ce qu’un vieux projet Bedrock a laissé s’accumuler. Plutôt que d’ignorer les avertissements, mieux vaut les traiter comme une liste de tâches concrète : un audit en --dry-run, des contraintes réécrites une par une, et une mise à jour de Bedrock isolée du reste. Le projet qu’on n’osait plus toucher redevient, petit à petit, un projet qu’on comprend.
