Ihr hebt Laravel, Symfony oder Drupal auf die nächste Version. Dann öffnet ihr die rector.php und sucht das passende Set. Version 10? 11? Habt ihr die alten Sets rausgenommen? Mit den Rector Composer Based Sets ist dieses Ratespiel vorbei. Rector liest die installierte Version direkt aus eurem Projekt und wählt die Regeln selbst. Das Rector Team hat das Feature in einem neuen Artikel ausführlich erklärt. Wir zeigen euch, wie es funktioniert, wie ihr es einrichtet und wie ihr es prüft. Den Gesamtüberblick zum Tool findet ihr in unserem Glossar zu Rector PHP.
Framework Upgrade mit Rector geplant?
Wir heben euer Projekt gemeinsam mit eurem Team auf aktuelle PHP und Symfony Versionen. Zuerst steht das Netz aus PHPStan, PHPUnit und Cypress E2E Tests, dann läuft Rector Schritt für Schritt.
Was sind Rector Composer Based Sets
Composer Based Sets koppeln Rector Regeln an eure installierten Paketversionen. Ihr sagt Rector nur, welche Frameworks im Spiel sind. Welche Version läuft, findet Rector selbst heraus. Das Feature gibt es seit Rector 2.6. So sieht die komplette Konfiguration aus, nicht nur ein Ausschnitt:
use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withComposerBased(
laravel: true,
drupal: true,
doctrine: true,
symfony: true,
phpunit: true,
);Keine Versionsnummer, kein Set für 10.0, das ihr nach dem Upgrade gegen 11.0 tauschen müsst. Ihr hebt das Paket, ihr startet Rector, fertig. Die Version steht an genau einer Stelle, in eurer composer.json.
Woher Rector die Version nimmt
Rector schaut zuerst in vendor/composer/installed.json. Dort steht, was wirklich im vendor Ordner liegt, also die exakte installierte Version. Fehlt die Datei, liest Rector die Abschnitte require und require-dev der composer.json.
Ein Beispiel: Ist laravel/framework 11.4.2 installiert, bekommt ihr die Laravel 11 Regeln. Nach einem composer update auf Version 12 laufen mit derselben rector.php auch die 12er Regeln. Die Konfiguration hat sich nicht geändert, nur die installierte Version.
Rector Composer Based Sets installieren
Für Symfony, Doctrine, PHPUnit und Twig braucht ihr nur Rector selbst ab Version 2.6, die Regeln stecken im Paket. Laravel und Drupal kommen über Community Erweiterungen, nämlich rector-laravel und drupal-rector:
composer require rector/rector --dev
# nur für Laravel Projekte
composer require driftingly/rector-laravel --dev
# nur für Drupal Projekte
composer require palantirnet/drupal-rector --devHabt ihr Rector schon im Projekt, reicht ein Update. Danach legt ihr die rector.php an oder erweitert eure bestehende. Schaltet nur die Pakete ein, die ihr wirklich nutzt:
use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
->withPhpSets()
->withComposerBased(
symfony: true,
doctrine: true,
phpunit: true,
twig: true,
);withPhpSets() ohne Parameter liest die PHP Version ebenfalls aus der composer.json. Zusammen mit withComposerBased() steht damit keine einzige Versionsnummer mehr in eurer Konfiguration. Alte Zeilen wie SymfonyLevelSetList::UP_TO_SYMFONY_74 könnt ihr nach dem Umstieg entfernen.
Welche Rector Regeln laufen wirklich
Automatik ist nur gut, wenn man sie nachvollziehen kann. Dafür gibt es den Befehl composer-based. Er listet jede versionsgebundene Regel mit Paket, geforderter Version, installierter Version und Status:
vendor/bin/rector composer-basedAuch inaktive Regeln tauchen in der Tabelle auf, samt der Version, ab der sie greifen würden. Die Frage, warum Rector eine Stelle nicht angefasst hat, beantwortet ihr damit in Sekunden. Danach zeigt der Dry Run den eigentlichen Diff:
vendor/bin/rector process --dry-runSo funktionieren Composer Based Sets intern
Hinter dem Feature stehen drei Mechanismen, von grob nach fein. Die Tabelle zeigt den Überblick:
| Ebene | Wie es funktioniert | Status |
|---|---|---|
| Set pro Paket | Ein ganzes Set lädt nur, wenn das Paket in passender Version installiert ist | Drupal nutzt das noch, SetProviderInterface ist deprecated |
| Regel mit eigener Version | Jede Regel nennt die Paketversion, ab der sie greift | Standard für Laravel, Symfony, Doctrine, Twig und PHPUnit |
| Konfiguration pro Version | Dieselbe Regel wird mehrfach mit eigener Konfiguration je Versionsbereich registriert | Laravel nutzt das für Klassen Umbenennungen |
Die erste Ebene hat einen Haken. Pro Version braucht es eine eigene Set Datei. Eine Regel, die ab Version 8 gilt, muss in die Dateien für 8, 9, 10 und 11 kopiert werden. Vergisst man eine, läuft die Regel für diese Version still nicht mehr. Deshalb gehen die Maintainer jetzt den anderen Weg: Jede Regel kennt ihre eigene Version.
Dafür implementiert eine Regel das ComposerPackageConstraintInterface. Passt die installierte Version nicht, filtert Rector die Regel aus, bevor die erste Datei geparst wird. Die Bedingung ist ein normaler Composer Versionsstring wie >=5.7 oder ^7.4:
use Rector\Rector\AbstractRector;
use Rector\VersionBonding\Contract\ComposerPackageConstraintInterface;
use Rector\VersionBonding\ValueObject\ComposerPackageConstraint;
final class MyLaravelRector extends AbstractRector implements ComposerPackageConstraintInterface
{
public function provideComposerPackageConstraint(): ComposerPackageConstraint
{
return new ComposerPackageConstraint('laravel/framework', '>=11.0');
}
// getNodeTypes(), refactor() und getRuleDefinition() wie gewohnt
}Für konfigurierbare Regeln gibt es ruleWithConfigurationComposerVersionBound(). Ein Beispiel ist RenameClassRector: Die Regel ist immer dieselbe, aber welche Klasse wann umbenannt wurde, hängt von der Version ab. So passt der ganze Laravel Upgrade Pfad in eine einzige Datei, statt in einen Ordner voller Dateien pro Version. Wer eigene Regeln schreibt, findet die Grundlagen in unserem Glossar zum Abstract Syntax Tree.
Rector für Laravel und Drupal
Laravel ist komplett auf das neue Modell umgezogen. Jede Regel ist an eine Version von laravel/framework gebunden. withComposerBased(laravel: true) und ihr seid fertig.
Drupal nutzt noch das ältere Set Modell, hat aber laut Rector Team über 80 Prozent automatisierte Abdeckung für Deprecations, getestet gegen fast 10.000 Contrib Module. Die Umstellung auf versionsgebundene Regeln läuft. Eure Konfiguration bleibt dabei gleich. Wie Drupal Teams das heute schon einsetzen, beschreibt der Artikel auf drupal.org.
Composer Based Sets im Team einführen
- Rector updaten: mindestens Version 2.6, besser gleich auf Rector 2.8.
- Alte Versionssets entfernen: Level Sets wie UP_TO_SYMFONY_74 durch
withComposerBased()ersetzen. - Prüfen:
vendor/bin/rector composer-basedzeigt, welche Regeln aktiv sind. - Dry Run lesen: den Diff reviewen, bevor Rector etwas schreibt.
- Absichern: nach jedem Lauf PHPStan und PHPUnit laufen lassen.
Das Feature nimmt euch die Pflege der Sets ab, nicht die Verantwortung. Bei uns gilt die feste Reihenfolge: erst die Quality Gates, dann das Aufräumen. Wie solche Gates aussehen, zeigt unser Artikel zu Quality Gates in der Pipeline. Wie ein komplettes Framework Upgrade abläuft, steht im Symfony Upgrade mit Rector auf 7.4 und 8. Nach Rector räumt Easy Coding Standard die Formatierung auf.
Fazit
Composer Based Sets machen Rector bei Framework Upgrades deutlich ruhiger. Die Version lebt an einem Ort, die Regeln folgen ihr automatisch, und ein einziger Befehl erklärt, was läuft. Für Teams, die regelmäßig Symfony, Laravel oder Drupal heben, spart das bei jedem Upgrade Sucharbeit und schließt eine stille Fehlerquelle. Euer composer.json wusste schon immer, welche Version ihr nutzt. Jetzt liest Rector mit.
Häufige Fragen zu Rector Composer Based Sets
Was sind Rector Composer Based Sets 2026?
Composer Based Sets koppeln Rector Regeln an eure installierten Paketversionen. Ihr aktiviert sie mit withComposerBased, Rector liest installed.json und composer.json und lädt nur Regeln, deren Versionsbedingung passt. Nach einem Framework Upgrade bleibt die rector.php unverändert.
Ab welcher Rector Version gibt es Composer Based Sets 2026?
Das Feature gibt es seit Rector 2.6. In den folgenden Versionen haben die Maintainer alle Erweiterungspakete auf versionsgebundene Regeln umgestellt. Aktuell ist Rector 2.8, das zusätzlich deutlich schneller läuft.
Welche Frameworks unterstützt withComposerBased 2026?
Symfony, Doctrine, Twig und PHPUnit sind direkt in Rector enthalten. Laravel und Drupal funktionieren über die Community Pakete rector-laravel und drupal-rector. Laravel nutzt bereits komplett versionsgebundene Regeln, Drupal wird gerade umgestellt.
Wie sehe ich 2026, welche Rector Regeln aktiv sind?
Mit vendor/bin/rector composer-based. Der Befehl zeigt jede versionsgebundene Regel mit Paket, geforderter und installierter Version und ob sie aktiv ist. Inaktive Regeln stehen mit der Version da, ab der sie greifen würden.
Brauche ich 2026 noch SymfonyLevelSetList in der rector.php?
Für Versionsupgrades nicht mehr. withComposerBased(symfony: true) wählt die Regeln passend zur installierten Symfony Version. Thematische Sets wie Code Quality oder Constructor Injection schaltet ihr weiter zusätzlich ein, wenn ihr sie nutzen wollt.
Quelle
Dieser Artikel basiert auf dem Beitrag Your composer.json Already Knows Which Rules to Run vom Rector Team. Weitere Details stehen in den Release Notes zu Rector 2.6.2. Angekündigt hat das Rector Team den Artikel auf X:
Rector Upgrades mit Never Code Alone
Wir stellen eure rector.php auf Composer Based Sets um, bauen Rector als Gate in eure Pipeline und sichern jedes Upgrade mit PHPStan und Tests ab. Kostenloses Kennenlernen, ehrliche Aufwandsschätzung, minutengenaue Abrechnung.
