Chapitre 14.6 — CS Fixer & Rector

Partie 14 : Tests & qualité — Chapitre 6/7 Version de référence : PHP CS Fixer 3 / Rector 2 / Symfony 7.4.

⏱️ TL;DR

• PHP CS Fixer applique un style de code cohérent (PSR-12 + règles Symfony) et le corrige automatiquement — fini les débats de mise en forme.
• Rector effectue des transformations sémantiques automatisées : montées de version PHP/Symfony, modernisation, améliorations de qualité — à l’échelle du projet.
• Différence : CS Fixer = style (espaces, ordre des imports…) ; Rector = sémantique (transformer du code, pas juste le reformater).
• Rector est l’outil clé pour migrer (Symfony 5→7, PHP 8.2→8.4 — cf. Partie 16).
• En CI, on les lance en mode vérification (--dry-run) : le build échoue si le code n’est pas conforme.
• Pour un dev Next.js : CS Fixer ≈ Prettier (+ ESLint stylistique), Rector ≈ des codemods (jscodeshift) — mais avec des règles prêtes pour les upgrades.

🎯 Objectifs

• Configurer et lancer CS Fixer.
• Configurer Rector et appliquer des règles.
• Distinguer style et transformation sémantique.
• Intégrer ces outils en CI.

1. PHP CS Fixer : le style

Un style cohérent évite les débats et les diffs pollués par la mise en forme. PHP CS Fixer applique un ensemble de règles et corrige le code.

composer require --dev friendsofphp/php-cs-fixer

// .php-cs-fixer.dist.php
$finder = (new PhpCsFixer\Finder())->in(__DIR__ . '/src')->in(__DIR__ . '/tests');
 
return (new PhpCsFixer\Config())
    ->setRules([
        '@PSR12' => true,
        '@Symfony' => true,                  // le style officiel Symfony
        'declare_strict_types' => true,      // impose declare(strict_types=1)
        'ordered_imports' => true,
        'no_unused_imports' => true,
    ])
    ->setFinder($finder);

Deux modes :

vendor/bin/php-cs-fixer fix              # CORRIGE le code
vendor/bin/php-cs-fixer fix --dry-run --diff   # VÉRIFIE (CI) : montre ce qui ne va pas, sans modifier

En local, on corrige ; en CI, on vérifie (--dry-run) et le build échoue si le style n’est pas respecté.

💡 Pour un dev Next.js : CS Fixer ≈ Prettier + les règles stylistiques d’ESLint, mais avec un preset @Symfony officiel. On le branche souvent en pre-commit hook (comme Prettier) pour formater avant de committer. Le résultat : un code uniforme dans toute l’équipe, des diffs propres.

2. Rector : la transformation sémantique

Là où CS Fixer reformate, Rector transforme le code : il comprend l’AST (arbre syntaxique) et applique des règles qui changent la sémantique — par exemple convertir une syntaxe ancienne en moderne, ou adapter du code à une nouvelle version.

composer require --dev rector/rector

// rector.php
use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\LevelSetList;
use Rector\Symfony\Set\SymfonySetList;
 
return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets(php84: true)                    // modernise vers PHP 8.4
    ->withSets([
        SymfonySetList::SYMFONY_74,               // adaptations Symfony 7.4
        LevelSetList::UP_TO_PHP_84,
    ])
    ->withPreparedSets(codeQuality: true, deadCode: true);   // qualité + code mort

vendor/bin/rector process --dry-run   # PRÉVISUALISE les changements
vendor/bin/rector process             # APPLIQUE

Exemples de ce que Rector fait automatiquement :

• convertir des tableaux array() en [] ;
• transformer une classe en promotion de constructeur (chapitre 2.5) ;
• remplacer une API dépréciée par son remplaçant (crucial pour les migrations) ;
• ajouter des types de retour manquants ;
• supprimer du code mort.

3. L’outil de migration : Rector pour les upgrades

Rector est l’ outil pour monter de version sans tout réécrire à la main. Migrer un projet de Symfony 5 → 6 → 7 (votre cas, cf. Partie 16) ou de PHP 8.1 → 8.4 : on applique les sets correspondants, et Rector transforme le code automatiquement (annotations → attributs, API dépréciées → remplaçants, etc.).

C’est ce qui rend la promesse de rétrocompatibilité (Partie 1.2) actionnable : Rector automatise le gros du travail de suppression des dépréciations. On revient sur la migration Symfony 5→7 en Partie 16.

⚠️ Piège : Rector modifie votre code — toujours l’exécuter sur un dépôt propre (rien de non-committé), en --dry-run d’abord, puis relire le diff et lancer les tests. Une transformation automatique peut se tromper sur un cas tordu. Rector fait 90 % du travail ; vous validez les 10 % (relecture + tests verts). Ne jamais rector process puis committer sans regarder.

4. CS Fixer vs Rector : complémentaires

On les utilise ensemble : Rector transforme, CS Fixer met en forme le résultat. Les deux tournent en CI (dry-run) et souvent en pre-commit.

✏️ Exercices

Exercice 1. Quelle commande CS Fixer utilise-t-on en local vs en CI, et pourquoi ?

Exercice 2. Vous devez migrer un projet de Symfony 6 / PHP 8.1 vers Symfony 7.4 / PHP 8.4. Quel outil et quelles précautions ?

Exercice 3. Quelle est la différence fondamentale entre CS Fixer et Rector ?

🧠 Quiz de révision

Prochain chapitre : 14.7 — CI GitHub Actions — automatiser tests et qualité sur chaque PR.