Composer 2.0 est maintenant disponible !

Par Laurent LOUIS-THERESEPHP, , Commentaires désactivés

Composer 2.0 quoi de neuf ?

La liste des changements et des améliorations est longue, consultez le changelog complet si vous souhaitez tout lire. Je vais souligner quelques points clés ici.

Amélioration des performances de Composer

Les équipes packagist ont remanié à peu près tout, du protocole utilisé entre Composer et packagist.org à la résolution des dépendances, en passant par le téléchargement de fichiers en parallèle à l’aide de curl et les optimisations de l’évaluation des contraintes. Cela conduit à des améliorations massives en termes de vitesse et d’utilisation de la mémoire. La différence dépend de votre cas d’utilisation. Bien que j’aie vu des rapports faisant état d’améliorations de plus de 50 % dans les deux cas dans certains projets, je ne peux pas donner de chiffre exact. Mais je suis sûr que vous serez agréablement surpris si vous n’avez pas encore essayé Composer 2.

En marge de cela, les requêtes/suppressions et les mises à jour partielles sont désormais beaucoup plus rapides car Composer ne charge désormais que les métadonnées des paquets en cours de modification.

composer 2.0

Le temps nécessaire à la mise à jour initiale et à l’installation (projet démarré, cache vide) est inférieur d’environ 60 % à celui utilisé par Composer 2 avec ext-curl activé.

Changements architecturaux et déterminisme

La façon dont les mises à jour des dépendances sont effectuées en interne a été remaniée, ce qui, pour vous, se traduira par des mises à jour plus déterministes. L’état local actuel du répertoire des fournisseurs n’interférera plus dans les mises à jour.

Une fois la mise à jour terminée, le processus d’installation est lancé automatiquement et il exécutera désormais toutes les opérations liées au réseau en premier – et en parallèle si possible. Cela évitera de vous laisser avec un répertoire de fournisseurs à moitié mis à jour si une erreur de réseau se produit au milieu de l’installation.

Fonctions d'exécution

Nous avons ajouté une étape de vérification de la plate-forme lors de l’initialisation de vendor/autoload.php qui vérifie que la version actuelle de PHP (et éventuellement les extensions) correspond à ce qui est attendu par vos dépendances et échoue dans le cas contraire. Cette étape est activée par défaut, alors assurez-vous d’en prendre connaissance pour éviter les surprises.

Il y a une nouvelle classe, Composer\InstalledVersions, qui est autoloadée dans chaque projet et est disponible à l’exécution. Elle vous permet de vérifier quels paquets/versions sont présents au moment de l’exécution de votre propre projet.

Consultez la documentation sur le runtime pour plus de détails.

Si votre code repose sur l’une de ces fonctionnalités d’exécution, vous devez exiger « composer-runtime-api » : « ^2.0 » dans votre composer.json. Il s’agit d’un paquet virtuel fourni par Composer qui garantit que les utilisateurs doivent utiliser Composer 2.x pour installer votre paquet.

Amélioration des rapports d'erreur

Parce que les choses ne se passent pas toujours comme elles le devraient, les devs du projet ont veillé à améliorer le rapport d’erreur qui vous est présenté lorsque les dépendances ne peuvent être résolues. Il est difficile de donner des exemples concrets ici, car il y a un million de façons dont cela peut échouer, mais vous remarquerez que les messages sont désormais plus courts, plus clairs et moins répétitifs.

Mises à jour partielles avec contraintes temporaires

Il peut parfois être utile de mettre à niveau ou de rétrograder un seul paquet vers une version spécifique, peut-être temporairement pour tester quelque chose ou attendre la correction d’un bug. Bonne nouvelle ! Vous pouvez maintenant exécuter composer update vendor/package:1.0.* par exemple (ou 1.0.12 ou toute autre contrainte de version), pour exécuter une mise à jour de vendor/package uniquement vers une version correspondant à cette contrainte supplémentaire. Cela ne mettra pas à jour votre require dans composer.json et ne marquera pas le fichier de verrouillage comme étant périmé.

Si vous souhaitez ajouter/restreindre une contrainte tout en effectuant une mise à jour complète de toutes les dépendances, vous pouvez utiliser update –with vendor/package:1.0.* qui exécutera la mise à jour avec cette contrainte supplémentaire.

La mise à niveau vers composer 2 est-elle facile ?

L’objectif de packagist est que chaque utilisateur de Composer puisse effectuer une mise à niveau en douceur et rapidement. Les gains sont énormes et il faut que le plus grand nombre de développeur php puisse en profiter. Pour y parvenir, quelques mesures sont à prendre tout de même :

Composer 2.0 prend toujours en charge PHP 5.3 et plus, tout comme Composer 1.x.
Les fichiers composer.lock sont interopérables entre les versions, vous pouvez donc passer à la version 2.0 et revenir en arrière facilement si nécessaire.
La plupart des commandes et des arguments restent les mêmes, et la plupart de ce que vous connaissez de Composer reste vrai dans la version 2.0.
Si vous exécutez composer self-update à partir de la version 1.x, il vous avertira qu’une nouvelle version majeure stable de Composer est disponible et que vous pouvez utiliser composer self-update –2 pour migrer vers celle-ci. Vous pouvez trouver des instructions spécifiques pour divers frameworks/CMSs/applications sur GitHub qui peuvent vous aider à effectuer la mise à niveau.

Si vous rencontrez des problèmes, vous pouvez revenir en arrière à tout moment en utilisant composer self-update –1. J’espère que cela permettra à chacun de se sentir à l’aise pour expérimenter la nouvelle version.

Si vous installez Composer automatiquement à partir du script d’installation et que vous souhaitez rester sur Composer 1.x pour le moment, vous pouvez également lui passer un argument –1 pour l’empêcher d’installer Composer 2.0 par défaut. Dans ce cas, n’oubliez pas de procéder à la mise à jour en temps voulu, car Composer 1.x ne sera pas maintenu très longtemps.

Voir La commande « self-update » n’est pas définie. ? Si vous avez installé Composer via le gestionnaire de paquets de votre système d’exploitation, la commande self-update peut ne pas être disponible. Utilisez quel compositeur pour trouver son chemin (par exemple /usr/bin/composer), puis exécutez le script d’installation en ajoutant –install-dir /usr/bin –filename composer (en ajustant le répertoire d’installation pour qu’il corresponde à votre chemin) à la ligne php composer-setup.php.

Des problèmes de rétrocompatibilité ?

Voici les principaux éléments susceptibles de causer des problèmes lors du processus de mise à niveau :

  • Les plugins : C’est probablement la principale source de problèmes pour la plupart des gens. Les plugins doivent être mis à jour pour prendre en charge Composer 2, et certains d’entre eux ne sont pas encore prêts. Composer 2 se plaindra et ne résoudra pas les dépendances si un plugin ne le supporte pas, donc pas besoin de trop réfléchir, vous pouvez l’essayer et voir comment ça se passe.
  • La nouvelle fonction de vérification de la plate-forme signifie que Composer vérifie la version PHP d’exécution et (éventuellement) les extensions disponibles pour s’assurer qu’elles correspondent aux dépendances du projet. Si une incompatibilité est trouvée, l’autochargeur se termine avec les détails de l’erreur pour s’assurer que les problèmes ne sont pas négligés. Pour éviter les problèmes lors du déploiement en production, il est recommandé d’exécuter composer check-platform-reqs avec le processus PHP de production dans le cadre de votre processus de construction ou de déploiement.
  • Priorité du référentiel : Si un paquet existe dans un dépôt de priorité supérieure, il sera désormais entièrement ignoré dans les dépôts de priorité inférieure. Si vous semblez manquer des paquets lorsque vous utilisez Composer 2, consultez la documentation sur les priorités de dépôt pour plus de détails.


Les configurations PSR-0 / PSR-4 invalides ne se chargeront plus automatiquement en mode optimisé, conformément aux avertissements introduits dans Composer 1.10. La plupart de ces avertissements concernaient des classes qui n’étaient pas censées se charger automatiquement de toute façon, donc je ne m’attends pas à des problèmes majeurs, mais il est plus sûr de les nettoyer avant la mise à niveau.
Si vous souhaitez en savoir plus, je vous recommande vivement de lire le guide UPGRADE qui comporte plusieurs sections destinées aux utilisateurs finaux, aux auteurs de plugins et aux responsables de la mise en œuvre du référentiel Composer.

Quelle est la prochaine étape ?

Nous ne disposons plus d’une feuille de route détaillée des fonctionnalités, car la version 2.0 contient des tonnes de nouveautés, mais il y a une chose importante que je souhaite expliquer : la prise en charge de la version PHP à l’avenir.

Comme je l’ai mentionné ci-dessus, Composer 2.0 prend en charge PHP 5.3+, qui est à ce jour très obsolète et rend le code difficile à maintenir par endroits. Nous nous sommes efforcés de faire en sorte que chaque utilisateur de Composer puisse passer à Composer 2, mais nous prévoyons d’abandonner la prise en charge des versions PHP obsolètes dans une future version mineure.

Composer 2.1 continuera à prendre en charge PHP 5.3, mais pour Composer 2.2, nous supprimerons la prise en charge de toutes les versions antérieures à PHP 7.1.3 ou PHP 7.2.5 en fonction de la date de sortie (à déterminer). D’après nos statistiques, cela permet à plus de 90% des utilisateurs de Composer d’utiliser la dernière version, et pour les autres qui sont bloqués sur des versions PHP obsolètes, nous continuerons à fournir des corrections de bogues et de sécurité critiques dans la gamme 2.0.x ou 2.1.x.

Quant à Composer 1.x, il est maintenant plus ou moins EOL. Il recevra également des correctifs critiques en cas de problème, mais l’objectif de chacun doit être de migrer vers la version 2.x dès que possible.