Symfony Docker

composer dump-autoload

La commande composer dump-autoload est une commande essentielle dans l’écosystème PHP/Composer. Elle régénère le fichier d’autoloading (chargement automatique des classes) sans réinstaller les dépendances. Voici ce qu’elle fait en détail :

---

À quoi sert composer dump-autoload ?

1. Reconstruit l’autoloader de Composer
   • Met à jour le fichier vendor/autoload.php qui gère le chargement automatique des classes PHP.
   • Utile quand vous ajoutez/modifiez des classes sans passer par composer install/update.
2. Optimise les performances (si utilisé avec -o)

   • Avec l’option --optimize (-o), Composer génère une version optimisée de l’autoloader (classe map statique), ce qui accélère le chargement des classes en production :

     composer dump-autoload --optimize
     

3. Prend en compte les classes dans autoload ou autoload-dev

   • Si vous avez des classes définies dans composer.json sous :

     "autoload": {
         "psr-4": { "MonApp\\": "src/" }
     }
     

   • La commande les intègre dans l’autoloader.

---

Quand l’utiliser ?

Cas d’usage	Commande recommandée
Après avoir ajouté une nouvelle classe manuellement (sans Composer).	composer dump-autoload
En production pour optimiser les performances.	composer dump-autoload --optimize
Après avoir modifié composer.json (sans vouloir réinstaller les dépendances).	composer dump-autoload
Pour vérifier les espaces de noms (PSR-4).	composer dump-autoload

---

Différence avec composer install et composer update

• composer install :
  

Installe les dépendances ET régénère l’autoloader.

• composer update :
  

Met à jour les dépendances ET régénère l’autoloader.

• composer dump-autoload :
  

Ne touche pas aux dépendances – ne fait que mettre à jour l’autoloader.

---

Exemple concret dans un projet Symfony

1. Vous ajoutez une nouvelle entité src/Entity/Product.php :

   • Symfony utilise l’autoloading PSR-4, donc la classe sera automatiquement détectée.
     

   • Si elle n’est pas reconnue, exécutez :

     composer dump-autoload
     

2. Vous développez un bundle local (lié via "type": "path" dans composer.json) :

   • Après avoir modifié le bundle, pour que Symfony reconnaisse les nouvelles classes :

     composer dump-autoload
     

---

Bonnes pratiques

• En développement :
  Utilisez composer dump-autoload après avoir ajouté des classes manuellement.
  

• En production :
  Utilisez composer dump-autoload --optimize pour des performances optimales.
  

• Avec Docker :
  Si vous montez un volume (./:/var/www/html), exécutez la commande dans le conteneur :

  docker-compose exec app composer dump-autoload
  

---

Résumé

composer dump-autoload est un outil léger pour rafraîchir l’autoloader sans toucher aux dépendances. Indispensable pour :
- Le développement de bundles locaux.
- L’ajout manuel de classes.
- L’optimisation en production.

Utilisez-la dès que vous rencontrez des erreurs du type :
> “Class ‘MonApp\Entity\Product’ not found”

🚀 Astuce : Combinez-la avec --optimize en prod pour un boost de performances !

Symfony cache et composer cache avec Docker :

---

1. Rôle du dossier /var/cache dans Symfony

Symfony utilise ce dossier pour : - Le cache applicatif (ex : compilation des templates Twig, cache des routes, annotations) - Le cache système (ex : fichiers de configuration compilés comme srcApp_KernelDevDebugContainer.php)

Problème avec Docker :
Par défaut, ce cache est régénéré à chaque démarrage du conteneur → ralentissements (surtout en dev).

---

2. Stratégies pour optimiser le cache avec Docker

A. Monter /var/cache en volume (pour le dev)

# docker-compose.yml
services:
  php:
    volumes:
      - ./var/cache:/var/www/html/var/cache  # Monte le cache Symfony

Avantages : - Le cache persiste entre les redémarrages du conteneur. - Meilleures performances en développement.

Inconvénients : - Peut causer des problèmes de permissions (solved avec chmod ou entrypoint.sh).

---

B. Utiliser un volume Docker nommé (prod + dev)

volumes:
  symfony_cache:  # Volume dédié pour le cache

services:
  php:
    volumes:
      - symfony_cache:/var/www/html/var/cache

Bonus : Ajoutez un entrypoint.sh pour fixer les permissions :

#!/bin/bash
set -e

# Fixe les permissions du cache
chown -R www-data:www-data /var/www/html/var

exec "$@"

---

C. Cache warming en production

Dans votre Dockerfile :

FROM composer AS builder
WORKDIR /app
COPY . .
RUN composer install --no-dev --optimize-autoloader

FROM php:8.2-fpm
COPY --from=builder /app /var/www/html
RUN php bin/console cache:warmup  # ⚡ Pré-chauffe le cache

---

3. Gestion des environnements

Environnement	Recommandation
Développement	Volume monté (./var/cache:/...) + chmod
Production	Volume nommé + cache warming dans l’image
CI/CD	Cache éphémère (pas de montage)

---

4. Exemple complet (docker-compose.yml)

version: '3.8'

volumes:
  symfony_cache:  # Pour le cache
  composer_cache: # Pour Composer

services:
  app:
    build: .
    volumes:
      - ./:/var/www/html
      - symfony_cache:/var/www/html/var/cache
      - composer_cache:/tmp/composer
    environment:
      APP_ENV: dev
      COMPOSER_CACHE_DIR: /tmp/composer

---

5. Bonnes pratiques

1. En dev : Montez var/cache pour éviter de tout recompiler.

2. En prod : Utilisez cache:warmup dans l’image + volume nommé.

3. Permissions : Résolvez-les via entrypoint.sh ou docker-compose :

   user: "${UID:-1000}:${GID:-1000}"
   

---

Différence avec Composer Cache

	Composer (~/.composer)	Symfony (/var/cache)
Type	Cache de dépendances	Cache applicatif
Montage	Toujours utile	Surtout en dev
Prod	Volume nommé recommandé	Warming dans l’image + volume

---

Résumé

• Oui, on peut appliquer le même principe de volume monté pour /var/cache.
  

• Mais : Symfony a besoin d’une gestion plus active (warming, permissions).
  

• Optimisez :
  • Dev → Volume monté + permissions
    

• • Prod → Cache warming + volumes nommés

Cela garantit des performances optimales dans tous les cas ! 🚀