TECHNOLOGIES / Composer
Composer : gestionnaire de dépendances PHP
Composer gère les dépendances de nos projets PHP : il installe, met à jour et verrouille les versions des packages tiers utilisés par Symfony et le reste de notre stack. C'est l'outil de référence de l'écosystème PHP moderne.
PRÉSENTATION
Qu'est-ce que Composer ?
Composer est le gestionnaire de dépendances officiel de l'écosystème PHP. À partir d'un fichier composer.json qui déclare les packages requis, il résout automatiquement les versions compatibles entre elles et génère un fichier composer.lock qui fige exactement les versions installées.
Ce verrouillage garantit que tous les environnements, développement, intégration, production, utilisent rigoureusement les mêmes versions de dépendances, en évitant les incohérences entre les machines de l'équipe.
Composer gère aussi l'autoloading des classes PHP selon la norme PSR-4, sans configuration manuelle : chaque package installé devient immédiatement utilisable dans le code.
FONCTIONNEMENT
Comment fonctionne Packagist
Packagist est le registre public officiel des packages Composer. Voici comment il s'articule avec un projet.
Registre public de packages
Packagist (packagist.org) est l'entrepôt central où sont référencés la quasi-totalité des packages PHP open source : Symfony, Doctrine, PHPUnit et des dizaines de milliers d'autres bibliothèques.
Résolution automatique des versions
Quand on exécute composer require, Composer interroge Packagist pour trouver les versions du package compatibles avec les contraintes déclarées et avec les autres dépendances déjà installées.
Synchronisation continue avec Git
Packagist est synchronisé automatiquement avec les dépôts Git des packages (GitHub, GitLab...) : chaque nouveau tag de version publié devient immédiatement disponible via Composer.
Packagist n'intervient qu'à la résolution
Une fois composer.lock généré, l'installation peut s'appuyer sur un cache local : Packagist n'est interrogé qu'au moment où les versions doivent être résolues, pas à chaque build.
REPOSITORY PRIVÉ
Gérer des repositories privés
Un repository privé n'est pas publié sur Packagist public. Voici les approches possibles pour le distribuer via Composer comme n'importe quel package tiers.
Déclaration directe dans composer.json
La solution la plus simple : ajouter une entrée repositories de type git pointant vers le dépôt du bundle, directement dans le composer.json du projet consommateur. La plus pratique pour un usage interne, quand les développeurs qui installent le projet ont aussi accès au dépôt du bundle, sans registre intermédiaire à maintenir.
Packagist.com
Service SaaS payant de l'éditeur de Composer (Private Packagist) qui héberge des repositories privés avec la même expérience que Packagist public : synchronisation automatique avec Git, gestion des accès par équipe, aucune infrastructure à maintenir.
Satis
Générateur de repository Composer statique, open source et auto-hébergé, développé par l'équipe Composer. Satis lit une configuration de dépôts Git et génère un fichier JSON statique servi par un simple serveur HTTP : pas d'abonnement, mais une infrastructure à maintenir soi-même.
BONNES PRATIQUES & DOCUMENTATION
Nos conventions Composer
Documentation de référence pour l'équipe SmartBooster.
Installer un package depuis un repository Git privé
Installer un package depuis un repository Git privé
Nos bundles internes (par exemple platform-core-bundle) ne sont pas publiés sur Packagist. Ils s'installent directement depuis leur dépôt Git en déclarant une entrée repositories dans le composer.json du projet consommateur.
"repositories": [
{
"type": "git",
"url": "git@gitlab.com:smartbooster/platform/platform-core-bundle.git"
}
],
Cette entrée indique à Composer d'aller chercher les tags et branches directement sur ce dépôt Git, en plus de Packagist. Le package se déclare ensuite normalement dans require, avec le nom défini dans son propre composer.json :
composer require smartbooster/platform-core-bundle:^1.0
Prérequis d'accès : la machine qui exécute composer install, poste de développement ou runner CI, doit disposer d'un accès SSH configuré vers le dépôt (clé déployée sur GitLab). Sans cet accès, Composer échoue avec une erreur d'authentification au moment de la résolution des dépendances.
Sur plusieurs projets : si le même bundle privé est consommé par plusieurs projets, préférer Packagist.com ou Satis plutôt que de dupliquer la déclaration repositories dans chaque composer.json. Passé deux ou trois projets, la maintenance des accès Git devient plus lourde que la mise en place d'un registre centralisé.
Mettre à jour un bundle privé
Mettre à jour un bundle privé
Une fois le bundle déclaré, la mise à jour suit le fonctionnement standard de Composer : aucune commande spécifique liée au repository Git.
composer update smartbooster/platform-core-bundle
Composer récupère les nouveaux tags disponibles sur le dépôt Git déclaré et sélectionne la version la plus haute compatible avec la contrainte de version présente dans composer.json.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Composer gère les dépendances PHP (bibliothèques Symfony, Doctrine...) tandis que npm et yarn gèrent les dépendances JavaScript (Vue.js, outils de build...). Un projet Symfony avec une interface Vue.js utilise généralement les deux en parallèle, chacun sur son propre écosystème : composer.json pour le backend PHP, package.json pour le frontend JavaScript.
Oui, systématiquement. Le fichier composer.lock fige les versions exactes installées et garantit que tous les environnements, développement, intégration, production, utilisent rigoureusement les mêmes versions. Ne pas le commiter revient à laisser chaque environnement résoudre ses propres versions, avec le risque de comportements différents entre les machines de l'équipe.
Composer refuse l'installation et affiche un message détaillant le conflit : quel package exige quelle contrainte de version, et pourquoi elles ne peuvent pas être satisfaites simultanément. Il faut alors soit assouplir une contrainte de version dans le composer.json, soit mettre à jour l'un des packages en conflit vers une version compatible avec l'autre.
La déclaration directe d'un repository Git dans le composer.json du projet suffit, sans passer par un registre intermédiaire. C'est la solution la plus rapide à mettre en place pour un usage interne, tant que les développeurs qui installent le projet ont un accès Git au dépôt du bundle. Packagist.com ou Satis deviennent pertinents quand le nombre de projets consommateurs augmente.
L'impact est limité si le cache Composer est conservé entre deux exécutions du pipeline CI : seules les nouvelles dépendances ou les mises à jour de versions déclenchent un téléchargement. Sans cache, chaque run réinstalle l'intégralité des packages depuis Packagist, ce qui peut ajouter plusieurs dizaines de secondes selon la taille du projet.
composer install installe exactement les versions figées dans composer.lock, sans jamais les changer : c'est la commande à utiliser en CI et sur les environnements de production. composer update recalcule les versions compatibles les plus récentes selon les contraintes du composer.json et régénère le composer.lock : c'est la commande à utiliser volontairement, en local, pour faire évoluer les dépendances.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.