Commencer→
Retour au cours

backend / php-laravel

Composer et autoloading

Leçon 61 exercice

Explication

Ce que vous allez apprendre

  • Comprendre le rôle de composer.json comme manifeste central d'un projet PHP
  • Différencier composer install (verrouillé, pour la prod/CI) de composer update (pour monter de version)
  • Comprendre comment la norme PSR-4 relie un namespace PHP à un dossier sur le disque
  • Ajouter une dépendance tierce et l'utiliser via un use explicite
  • Optimiser l'autoloader avant un déploiement en production

Dans quel contexte ?

Une équipe backend démarre un nouveau projet et doit intégrer une bibliothèque tierce (un client HTTP comme Guzzle) sans gérer manuellement son téléchargement, ses dépendances et ses mises à jour de sécurité. Composer résout ce problème une fois pour toutes : il devient impossible d'imaginer un projet PHP professionnel moderne sans lui, exactement comme npm pour Node.js.

D'abord, un problème que Composer résout entièrement

Avant Composer, ajouter une bibliothèque PHP à un projet signifiait télécharger manuellement son code, gérer ses propres dépendances une par une, et espérer qu'aucune version ne soit incompatible avec une autre bibliothèque déjà utilisée. composer.json centralise tout ça : il déclare quelles dépendances le projet a besoin, avec quelles contraintes de version.

composer require guzzlehttp/guzzle ajoute une dépendance et l'enregistre automatiquement à la fois dans composer.json (la contrainte, ex: ^7.8) et dans composer.lock (la version exacte réellement installée).

Prérequis

Il faut être à l'aise avec les namespaces PHP (namespace Acme\Boutique\Service;) déjà croisés en filigrane dans les leçons précédentes sur la POO.

Ensuite, pourquoi deux commandes différentes pour installer ?

composer install installe exactement les versions figées dans composer.lock, sans jamais chercher de mise à jour : c'est la commande à utiliser en CI et en production, pour garantir que tout le monde tourne avec exactement les mêmes versions. composer update, à l'inverse, recalcule les meilleures versions compatibles selon les contraintes de composer.json et met à jour composer.lock en conséquence.

CommandeUtiliseContexte recommandé
composer installcomposer.lock (versions figées)CI, production, nouveau clone du repo
composer updatecomposer.json (contraintes)Développement, montée de version volontaire

Piège fréquent

Lancer composer update directement en production peut installer des versions plus récentes non testées de certaines dépendances, avec un risque de régression. La règle stricte : composer.lock doit être commité dans le dépôt Git, et seul composer install doit s'exécuter en prod/CI.

Il reste à comprendre comment PHP retrouve une classe sans require manuel

C'est là qu'intervient PSR-4, une convention qui relie un préfixe de namespace à un dossier physique. Dans l'exemple, "Acme\Boutique\": "src/" signifie que la classe Acme\Boutique\Service\PanierService doit se trouver exactement dans src/Service/PanierService.php. Cette correspondance stricte permet à Composer de générer un autoloader qui charge la bonne classe à la demande, sans qu'on écrive le moindre require.

Maintenant, un seul point d'entrée pour tout charger

Une fois l'autoload configuré, un unique require __DIR__ . '/vendor/autoload.php'; en tout début de script suffit à rendre disponibles toutes les classes du projet ET de ses dépendances. C'est ce même mécanisme que Laravel utilise en interne pour charger tout son framework.

Astuce

composer dump-autoload -o régénère l'autoloader en mode optimisé (classmap figé), à exécuter systématiquement avant un déploiement en production : ça évite à PHP de devoir résoudre dynamiquement les chemins PSR-4 à chaque requête, un gain de performance mesurable.

Maintenant que tu sais gérer les dépendances d'un projet PHP pur, tu es prêt à découvrir Laravel lui-même, qui repose entièrement sur ce mécanisme Composer : la prochaine leçon installe et explore la structure d'un premier projet Laravel.

Commandes & code

Composer et autoloading

json
// composer.json : manifeste du projet, équivalent PHP de package.json
{
    "name": "acme/boutique",
    "description": "Application de e-commerce",
    "type": "project",
    "require": {
        "php": "^8.2",
        "guzzlehttp/guzzle": "^7.8"
    },
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    },
    "autoload": {
        "psr-4": {
            "Acme\\Boutique\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Acme\\Boutique\\Tests\\": "tests/"
        }
    }
}
bash
# Commandes Composer essentielles
composer init                     # crée composer.json interactivement
composer require guzzlehttp/guzzle  # ajoute une dépendance et la verrouille dans composer.lock
composer require --dev phpunit/phpunit  # dépendance de développement uniquement
composer install                  # installe exactement les versions de composer.lock (CI/prod)
composer update                   # met à jour selon les contraintes de composer.json
composer dump-autoload -o         # régénère l'autoloader, -o l'optimise (classmap figé, prod)
composer show -o                  # liste les paquets obsolètes
php
<?php
// PSR-4 : le namespace Acme\Boutique\ correspond au dossier src/
// donc Acme\Boutique\Service\PanierService vit dans src/Service/PanierService.php

namespace Acme\Boutique\Service;

use Acme\Boutique\Model\Produit;         // import explicite d'une classe
use GuzzleHttp\Client;                      // dépendance tierce installée via Composer

class PanierService {
    private array $lignes = [];

    public function __construct(private readonly Client $httpClient) {}

    public function ajouter(Produit $produit, int $quantite): void {
        $this->lignes[] = compact('produit', 'quantite');
    }

    public function total(): float {
        return array_sum(array_map(
            fn($ligne) => $ligne['produit']->prix * $ligne['quantite'],
            $this->lignes
        ));
    }
}

// Point d'entrée : un seul require pour tout charger
require __DIR__ . '/vendor/autoload.php';

use Acme\Boutique\Service\PanierService;
use Acme\Boutique\Model\Produit;

$service = new PanierService(new \GuzzleHttp\Client());
$service->ajouter(new Produit("Clavier", 49.99), 2);
echo $service->total() . "
";

Résumé

  • composer.json déclare dépendances et règles d'autoload PSR-4 (namespace -> dossier).
  • composer install (verrouillé par composer.lock) en CI/prod, composer update en dev pour monter de version.
  • vendor/autoload.php est le seul require nécessaire dans toute l'application.
  • composer dump-autoload -o optimise le chargement des classes en production.

Exercices pratiques

1 disponible
1

Mission : reparer un deploiement casse par composer update

Objectif : Diagnostiquer un incident de production cause par une mauvaise utilisation de Composer, puis corriger la configuration PSR-4.

Contexte

Un script de deploiement automatique execute par erreur composer update au lieu de composer install directement sur le serveur de production. Le lendemain, une bibliotheque tierce s'est mise a jour vers une version majeure incompatible, cassant une fonctionnalite critique. En parallele, un developpeur signale que sa nouvelle classe Acme\Boutique\Service\PanierService provoque une erreur "Class not found", alors que le fichier existe bien sur le disque a l'emplacement src/Services/PanierService.php.

Résoudre l’exercice →