Chapitre 1.3 — L’écosystème : Composer, Flex, bundles, API Platform, UX

Partie 1 : Découvrir Symfony — Chapitre 3/5 Version de référence : Symfony 7.4 LTS (novembre 2025, PHP 8.2+).

⏱️ TL;DR

• Composer est le npm de PHP : il lit un composer.json, résout les dépendances, les installe dans vendor/ et fige les versions dans composer.lock.
• Packagist est le npmjs.com de PHP : le registre public des paquets.
• Symfony Flex est un plugin Composer magique : quand vous installez un paquet, il applique une recipe qui configure automatiquement le paquet (fichiers de config, variables .env, enregistrement du bundle). Il fournit aussi des alias courts (composer require orm).
• Un bundle est un « plugin » Symfony : un paquet qui ajoute des fonctionnalités au framework. Depuis Symfony 4, votre application n’est plus un bundle.
• L’écosystème premium : API Platform (créer des API en un attribut), Symfony UX (JS moderne sans SPA), SymfonyCasts (tutoriels vidéo de référence), Symfony CLI (outil en ligne de commande).
• Pour un dev Next.js : composer ↔ npm/pnpm, composer.json ↔ package.json, vendor/ ↔ node_modules/, Packagist ↔ npm registry. Flex n’a pas d’équivalent JS — c’est du « create-next-app » qui s’exécuterait à chaque install.

🎯 Objectifs

• Manipuler mentalement Composer et Packagist en les mappant sur ce que vous connaissez de npm.
• Comprendre ce qu’est une recipe Flex et pourquoi elle rend Symfony si rapide à démarrer.
• Définir un bundle et savoir où il s’enregistre.
• Situer API Platform, Symfony UX et les ressources d’apprentissage clés dans l’écosystème.

1. Composer : le gestionnaire de dépendances de PHP

Rien ne se fait en PHP moderne sans Composer. C’est l’outil qui gère les dépendances de votre projet. Si vous connaissez npm/pnpm, la correspondance est quasi parfaite :

Un composer.json minimal ressemble à ceci :

// composer.json (extrait)
{
    "require": {
        "php": ">=8.2",
        "symfony/framework-bundle": "7.4.*",
        "symfony/runtime": "7.4.*"
    },
    "autoload": {
        "psr-4": { "App\\": "src/" }
    }
}

La ligne "App\\": "src/" dit à Composer : « la classe App\Entity\Booking se trouve dans src/Entity/Booking.php ». C’est l’autoload PSR-4 — on le détaille en Partie 2. Retenez : pas de require manuel de fichiers, pas d’import relatif fragile ; on référence une classe par son namespace, et Composer sait où la charger.

⚠️ Piège : on committe composer.json et composer.lock, mais jamais vendor/ (comme on ne committe jamais node_modules/). Sur le serveur, on lance composer install --no-dev --optimize-autoloader pour reconstruire vendor/ à l’identique du .lock.

💡 Pour un dev Next.js : composer.lock joue le rôle exact de votre lockfile. composer install respecte le lock (reproductible) ; composer update recalcule les versions (comme npm update). La distinction install/update est la même que côté JS — et la même source de bugs quand on les confond.

2. Packagist : le registre public

Packagist.org  est le registre central où sont publiés les paquets PHP open source. Chaque paquet a un nom de la forme vendor/nom : symfony/console, doctrine/orm, api-platform/core, stripe/stripe-php… Quand vous faites composer require symfony/console, Composer interroge Packagist, résout les versions compatibles, télécharge, et met à jour composer.json + composer.lock.

Pour publier votre propre paquet (un bundle réutilisable, monnayable — cf. Partie 15), vous le poussez sur GitHub et l’enregistrez sur Packagist. On verra ça concrètement.

3. Symfony Flex : la magie du démarrage

C’est la pièce qui distingue l’expérience Symfony moderne. Flex est un plugin Composer activé par défaut dans tout projet Symfony. Il fait deux choses :

3.1 Les alias

Flex ajoute des raccouris aux noms de paquets. Au lieu de retenir symfony/orm-pack, vous tapez :

composer require orm        # → installe et configure Doctrine ORM
composer require twig       # → installe et configure Twig
composer require api         # → installe et configure API Platform
composer require --dev maker # → installe le MakerBundle (générateurs de code)

3.2 Les recipes (le vrai super-pouvoir)

Une recipe est une recette d’installation associée à un paquet, hébergée dans un dépôt public (github.com/symfony/recipes ). Quand Flex installe un paquet qui a une recipe, il exécute automatiquement la configuration :

Résultat : composer require en PHP ne fait pas que télécharger — il branche le paquet dans votre application. C’est ce qui permet à un projet Symfony de rester minuscule au départ et de grandir proprement : chaque fonctionnalité arrive avec sa config au bon endroit.

💡 Pour un dev Next.js : il n’y a pas d’équivalent dans npm. Le plus proche serait un create-next-app qui s’exécuterait à chaque npm install <pkg> pour câbler automatiquement le package (créer les fichiers de config, ajouter les variables d’env, brancher le plugin). Flex, c’est ça — de l’« installation qui configure ».

⚡ Depuis Symfony 5 : Flex existait déjà en 5, mais l’écosystème de recipes s’est beaucoup enrichi et fiabilisé. Autre changement de fond : on ne parle plus de website-skeleton (le squelette « tout inclus » de l’ère 4/5, aujourd’hui abandonné). On part d’un squelette minimal et on ajoute des packs (webapp) selon les besoins. Si vous aviez le réflexe « `composer create-project symfony/website-skeleton » », il est périmé (cf. Partie 3).

4. Les bundles : les « plugins » de Symfony

Un bundle est un paquet qui étend le framework : il apporte des services, de la configuration, des routes, des commandes, des templates… Exemples que vous croiserez :

Les bundles activés sont listés dans un simple fichier PHP :

// config/bundles.php
return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Symfony\Bundle\TwigBundle\TwigBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
    // … ajouté automatiquement par les recipes Flex
];

⚡ Depuis Symfony 5 — le changement mental le plus important : votre application n’est plus un bundle. Jusqu’à Symfony 3, on codait dans un AppBundle ou des bundles par module. Depuis Symfony 4, le code applicatif vit directement dans src/ sous le namespace App\, sans bundle. Les bundles sont désormais réservés au code réutilisable/partagé (le vôtre publié sur Packagist, ou ceux des tiers). Ne cherchez pas votre AppBundle : il n’existe plus.

5. L’écosystème premium (ce qui rend Symfony pertinent pour vous)

Au-delà du framework, trois briques comptent particulièrement pour un dev Next.js :

• API Platform — un framework d’API bâti sur Symfony. En annotant une classe avec #[ApiResource], vous obtenez une API REST + GraphQL complète (CRUD, pagination, filtres, validation, doc OpenAPI/Swagger, format JSON-LD/Hydra) quasi gratuitement. C’est le cœur premium de ce cours (Partie 11) et la clé du couple Symfony API ↔ front Next.js.

• Symfony UX — un ensemble de composants qui apportent du JavaScript moderne sans SPA : Stimulus (petits contrôleurs JS), Turbo (navigation et mises à jour partielles sans recharger), LiveComponents (composants serveur réactifs). On les compare frontalement à React en Partie 8.

• SymfonyCasts (symfonycasts.com ) — les tutoriels vidéo de référence, produits par des proches du core. Si un jour vous bloquez, c’est la ressource n°1.

Autres pièces utiles à connaître de nom : Symfony CLI (l’outil symfony en ligne de commande : serveur local, vérifications, déploiement — Partie 3), MakerBundle (générateurs), Doctrine (ORM/DBAL — Partie 6), Mercure (temps réel — Partie 12).

6. La communauté et les ressources officielles

• Documentation : symfony.com/doc  — dense, complète, versionnée. La référence absolue.
• The Symfony Book et « Symfony: The Fast Track » (livre gratuit de Fabien Potencier) — parcours guidé officiel.
• Symfony Demo : une application d’exemple officielle (github.com/symfony/demo ) pour lire du « vrai » code Symfony idiomatique.
• Communauté : Slack/Discord Symfony, le forum, les SymfonyLive/SymfonyCon (conférences), et une certification officielle (utile sur un profil freelance — cf. Partie 17).

📚 Aller plus loin : gardez trois onglets ouverts pendant tout ce cours — symfony.com/doc , api-platform.com/docs  et packagist.org . Ce sont vos trois sources de vérité.

✏️ Exercices

Exercice 1. Établissez la table de correspondance complète entre l’outillage JS que vous connaissez et l’outillage PHP (au moins 5 lignes).

Exercice 2. Expliquez ce que fait composer require api dans un projet Symfony, étape par étape, en insistant sur le rôle de Flex.

Exercice 3. Vrai ou faux, et corrigez si besoin : « Dans une application Symfony 7.4, mon code applicatif vit dans un AppBundle. »

🧠 Quiz de révision

Prochain chapitre : 1.4 — Symfony vs le monde — face à Laravel, face à Node (Express/NestJS), et face aux API routes de Next.js : ce que Symfony apporte à un dev JS.