Rector Symfony Laravel Package

Technical Evaluation

Architecture fit. rector/rector-symfony is not a runtime library — it is a set of Rector rules (declarative AST transformations) packaged as a split from the main Rector distribution. It is a dev-only dependency with zero production footprint, wired in through rector.php via ->withSets([SymfonySetList::...]). Architecturally this is a low-risk, additive tool: it touches nothing at runtime, requires no framework bootstrapping beyond what Rector already does, and is gated by CI.

Critical scope note. Despite being framed as a "Laravel/PHP" package, this is a Symfony-specific ruleset. It has no direct value for pure Laravel application code — Laravel modernization lives in rectorphp/rector (core) and driftingly/rector-laravel. Realistic fit for a Laravel-centric shop is limited to: (a) in-house packages that support Symfony versions, (b) Symfony components inside the dependency graph (HttpFoundation, Console, Finder, Process, VarDumper), and (c) legacy Symfony services/bundles being migrated into or alongside the Laravel stack. Confirm we actually own Symfony-versioned code before sponsoring adoption.

Integration feasibility. High. composer require --dev rector/rector rector/rector-symfony, add a set to rector.php, run vendor/bin/rector process --dry-run to preview, then apply. No schema changes, no service registration, no deployment pipeline changes beyond a CI job. Reversible via git.

Technical risk.

• Transformation correctness (primary). Rector rules can be incomplete (missed deprecations) or, more rarely, semantically wrong on exotic patterns (magic methods, dynamic property access, macros). Requires meaningful test coverage to validate diffs.
• Version skew (secondary). rector/rector-symfony major must track rector/rector major; Symfony set lists are version-gated (5.4 → 6.0 → 6.4 → 7.x). Misaligned pins silently no-op or error.
• Ecosystem signal. 239 stars and 0 recorded dependents is a data artifact — most consumers get these rules bundled inside rector/rector rather than installing the split directly. Still, verify via Packagist download stats before treating maturity as proven.
• Maintainer concentration. Community-maintained by the Rector core team; healthy but small. No commercial SLA.

Key questions for the team.

1. Which Symfony version jump are we targeting, and is it a single hop or a multi-step ladder?
2. What is our current test coverage on the affected code — can we detect a bad transformation automatically?
3. Are we on Rector 1.x (rules bundled) or 2.x (split packages)? This determines whether we install this at all.
4. Do we maintain any in-house bundles/rules that Rector cannot cover, requiring custom rules?
5. Is the codebase owned by a team with a Rector champion, or will this be an orphaned tool?

Integration Approach

Stack fit. Low-friction, dev-toolchain-only. It sits alongside PHPStan, Pint/CS-Fixer, and PHPUnit as a static-analysis-adjacent step. No application code changes, no container/DI impact, no runtime dependency tree pollution.

Migration path.

1. Add rector/rector + rector/rector-symfony as require-dev, pinned to exact minors.
2. Establish a baseline --dry-run and archive the output as the "before" snapshot.
3. Sequence rulesets lowest-risk first: PHP version sets → dead code / code quality → Symfony deprecation sets → Symfony major-version upgrade sets. One PR per ruleset, never mixed.
4. Gate every application PR on the full test suite; treat any test failure as a rule defect, not a test defect, until proven otherwise.
5. Merge per-directory or per-bundle to keep diffs reviewable on large codebases.

Compatibility. Hard constraints: PHP floor of the target Symfony version, Rector major version, and Symfony major version. Maintain a compatibility matrix in the repo README. If the codebase spans multiple Symfony versions (multi-package monorepo), run the tool per-package with scoped withPaths() rather than repo-wide.

Sequencing recommendation. Do not bundle the Symfony upgrade with an unrelated framework or PHP-version migration. Land the Rector tooling and baseline in sprint N, run the Symfony ladder in sprints N+1 and N+2, and keep a dedicated branch per version hop so any hop can be reverted independently.

Operational Impact

Maintenance. Low steady-state: a pinned dev dependency upgraded on the same cadence as Rector itself (~2–4 minor bumps/year). The ruleset must be re-evaluated at each Symfony major release. Budget roughly one engineer-day per Symfony major cycle plus the migration effort itself.

Support. Community-only — GitHub issues, no SLA. Acceptable for a dev tool where failure means "we fix the diff by hand," not "production is down." Escalation option exists via paid Rector consulting if the migration becomes business-critical.

Scaling. Rules execute per-file and scale linearly with codebase size; a mid-size codebase (5k–20k files) will take minutes. Use Rector's parallel mode and CI caching. Memory ceilings are the realistic constraint on very large monorepos — expect to shard by path.

Failure modes and mitigations.

• Silent no-op (wrong version pin, set not registered) → assert in CI that the dry-run reports a non-zero change count on a known-to-change fixture.
• Incorrect transformation → mandatory test suite gate; require human review on every auto-generated diff; never auto-merge.
• Parse failure on exotic syntax → scope withPaths() to exclude unparseable legacy dirs; document the exclusion list.
• Config drift → commit rector.php and version-pin it; treat it as code, not local config.

Ramp-up. Low for engineers already comfortable with static analysis; roughly half a day to configure and validate the first ruleset, one to two days to train the team on diff-review discipline. The real cost is review bandwidth during the migration window, not tooling. Recommend designating a single Rector champion to own config, rule selection, and the upgrade ladder — otherwise the tool stalls after the initial run.