Chapitre 3.3 — Créer le projet Symfony

Partie 3 : Installation & environnement — Chapitre 3/5 Version de référence : Symfony 7.4 / Flex.

⏱️ TL;DR

• Deux façons de créer un projet : symfony new mon-projet --version="7.4.*" (via la CLI) ou composer create-project symfony/skeleton:"7.4.*" mon-projet.
• Deux « tailles » de départ : le squelette minimal (idéal pour une API/microservice) ou le squelette --webapp (ajoute Twig, formulaires, sécurité, assets… pour le full-stack).
• Comme BookLab est full-stack + API, on part du --webapp puis on ajoute API Platform à la demande.
• Flex applique les recipes à chaque composer require : la config arrive automatiquement.
• On ajoute le MakerBundle (composer require --dev maker) : un générateur de code (entités, contrôleurs, formulaires…) qui accélère énormément.
• Vérification finale : symfony serve → la page de bienvenue Symfony s’affiche.

🎯 Objectifs

• Créer un projet Symfony 7.4 avec la bonne « taille » de squelette.
• Comprendre ce que --webapp ajoute et pourquoi.
• Voir Flex appliquer une recipe en direct.
• Installer le MakerBundle et servir la page d’accueil.

1. Deux commandes équivalentes

# via la Symfony CLI (recommandé : gère la version PHP, propose --webapp)
symfony new booklab --version="7.4.*"
 
# ou via Composer directement
composer create-project symfony/skeleton:"7.4.*" booklab

Les deux téléchargent le squelette Symfony (un projet minimal : le strict nécessaire pour répondre à une requête) et lancent composer install. La CLI ajoute des commodités (choix de la version PHP, drapeau --webapp).

2. Minimal vs --webapp : choisir sa taille de départ

Symfony ne vous impose pas tout d’un coup. Vous choisissez le point de départ :

Le drapeau --webapp installe le pack symfony/webapp-pack : un méta-paquet qui tire, en une fois, l’ensemble des composants d’une application web classique. Sans lui, vous ajoutez chaque brique à la demande (composer require twig, composer require security, etc.).

⚡ Depuis Symfony 5 : c’est le remplaçant de l’ancien website-skeleton (abandonné). On ne fait plus composer create-project symfony/website-skeleton. On part du skeleton (minimal) et on ajoute --webapp (ou les packs) selon le besoin. Ce modèle « minimal qui grandit » est au cœur de la philosophie Flex.

Pour BookLab (full-stack et API), on part de --webapp :

symfony new booklab --version="7.4.*" --webapp
cd booklab

💡 Pour un dev Next.js : --webapp ≈ un create-next-app avec toutes les options cochées (routing, styling, etc.), tandis que le skeleton minimal ≈ un projet Node « nu » où vous ajoutez Express, un ORM, etc. à la main. Flex rend l’ajout ultérieur indolore (config automatique), donc partir minimal n’est pas un piège comme en JS.

3. Flex en action : une recipe, en direct

Ajoutons une dépendance et observons Flex. Par exemple, un client HTTP :

composer require symfony/http-client

Sortie typique :

Using version ^7.4 for symfony/http-client
...
Symfony operations: 1 recipe (xxxx)
  - Configuring symfony/http-client (>=x): ...
...

Flex a résolu la version, installé le paquet et appliqué sa recipe (ici, création éventuelle de config/packages/framework.yaml mis à jour, variables .env…). Vous n’avez rien configuré manuellement.

Autre exemple, très visuel — ajouter Doctrine ORM :

composer require orm      # alias Flex → symfony/orm-pack (Doctrine)

La recipe crée config/packages/doctrine.yaml, ajoute DATABASE_URL dans .env, enregistre le DoctrineBundle. En une commande, l’ORM est prêt.

4. Le MakerBundle : votre générateur de code

Le MakerBundle génère du code idiomatique (entités, contrôleurs, formulaires, commandes, utilisateurs de sécurité…). On l’installe en dépendance de dev :

composer require --dev maker

Il expose des commandes make:* :

php bin/console list make        # liste tous les générateurs disponibles
php bin/console make:controller  # crée un contrôleur (+ template + test)
php bin/console make:entity      # crée/complète une entité Doctrine (interactif)
php bin/console make:command     # crée une commande console

make:entity est interactif : il vous demande les champs, leurs types, s’ils sont nullables, et génère l’entité + son repository avec les bons attributs. On s’en servira dès la Partie 6 pour bâtir le modèle de BookLab.

⚠️ Piège : le MakerBundle génère du code, il ne le maintient pas. Après génération, le code est à vous : relisez-le, adaptez-le. Ce n’est pas de la magie runtime (contrairement aux attributs), juste un gain de temps à l’écriture. Et comme c’est du --dev, il n’est pas déployé en prod.

5. Vérifier : la page de bienvenue

symfony serve -d
symfony open:local          # ouvre le navigateur sur https://localhost:8000

Vous devez voir la page de bienvenue Symfony (« Welcome to Symfony »). Elle n’apparaît que tant qu’aucune route ne répond à / — c’est normal, on la remplacera. Si vous la voyez, tout fonctionne : PHP, Composer, la CLI, le squelette.

php bin/console about        # récapitulatif : version Symfony, PHP, env, chemins

bin/console about affiche un tableau de bord de votre installation (version de Symfony, de PHP, environnement actif, dossiers de cache/log) — pratique pour un diagnostic rapide.

✏️ Exercices

Exercice 1. Vous démarrez une API pure (consommée par un front Next.js, pas de HTML côté Symfony). Quel squelette choisissez-vous et pourquoi ?

Exercice 2. Après composer require orm, vous constatez qu’un fichier config/packages/doctrine.yaml et une variable DATABASE_URL sont apparus sans action de votre part. Qui a fait ça ?

Exercice 3. Pourquoi installe-t-on le MakerBundle en --dev, et quelle en est la conséquence en production ?

🧠 Quiz de révision

Prochain chapitre : 3.4 — Arborescence & configuration — .env et .env.local, config/, les environnements dev/prod/test, et les secrets.