Rector Src Laravel Package

Product Decisions This Supports

• Roadmap sequencing for PHP/framework upgrades. Rector is an automated refactoring engine for PHP: it applies rule-based AST transformations to upgrade code (e.g., PHP 7.4 → 8.3, Laravel 9 → 11, Symfony 5 → 6) and modernize legacy patterns. This turns "we can't upgrade because it's a 6-month manual slog" into a scoped, resourced workstream with measurable throughput — a direct input to when you can commit to dropping EOL runtimes or unlocking framework features.
• Build vs. buy for codemods. If your roadmap contains repeated mechanical migrations (deprecated API swaps, DI container rewrites, type-hint backfill, PSR-12/12 normalization, custom internal-framework API changes), Rector is the buy option: an engine plus a rule library, extensible with in-house rules. Building this in-house means owning a PHP parser, scope analysis, and printing/printer fidelity — a multi-quarter investment for a non-differentiating capability.
• Tech-debt investment cases. Provides a credible, quantifiable story: "X% of upgrade diff is automatable; remaining Y% needs human review." That converts a vague modernization ask into an estimate with a review-burden line item instead of a blanket guess.
• Standardization and platform-team leverage. A shared rule set becomes an internal platform artifact — one team encodes the conventions and framework migrations, every product team runs them in CI. This supports decisions about standing up a developer-productivity/platform function vs. federating upgrades to each squad.
• Deprecation and sunset decisions. If Rector can mechanically migrate your usage of an internal library or vendor package, the cost of killing that dependency drops, which changes the calculus on end-of-life-ing internal services, consolidating duplicate packages, or replacing a framework.
• CI quality-gate policy. Rector's --dry-run mode lets you enforce "no deprecated APIs / no legacy patterns" as a merge gate, which is a policy decision (freeze the debt vs. tolerate it) backed by a tool rather than a wiki page.
• Staffing and timeline for upgrade programs. Because rule coverage maps to specific version hops, you can decide whether an upgrade is a 2-sprint chore or an initiative, and whether to fund a dedicated migration squad.

Important scoping caveat for the decision record: rector/rector-src is the development repository — the monorepo where Rector itself is built. It has 140 stars and zero dependents precisely because it is not the installable artifact. The distribution package product teams should evaluate and depend on is rectorphp/rector. Any decision memo or procurement line item referencing rector-src as a dependency is a category error; treat rector-src only as the place you'd read the implementation, or contribute rules upstream.

When to Consider This Package

Consider it (i.e., consider rectorphp/rector, with rector-src as the upstream source) when:

• You maintain one or more long-lived PHP codebases on a version or framework that is approaching or past end-of-life, and the upgrade is blocked by manual effort rather than by product priorities.
• You are planning a major-version jump — PHP 7.x → 8.x, Laravel, Symfony, PHPUnit, Doctrine — where the vendor publishes deprecation guidance that can be encoded as rules.
• You have many repositories sharing conventions, where paying the cost of writing a rule once beats N manual passes and N code-review cycles.
• You have meaningful automated test coverage (or can fund building it). Rector rewrites code; tests are the safety net that decides whether the output is trustworthy. Adoption without tests converts an efficiency win into an incident generator.
• You want a repeatable, reviewable diff rather than a big-bang rewrite — Rector's output is a normal pull request, which fits existing review and rollback practices.
• You have, or can borrow, someone who can write PHP rules (a custom RectorRule is a modest, well-documented unit of work). This is the real adoption cost, and it's where platform teams earn their keep.

Look elsewhere, or defer, when:

• You don't have a PHP codebase. Sounds obvious; it eliminates most of the value. This is a PHP-specific bet.
• The codebase is small or short-lived. For a service with a few thousand lines and a planned replacement, a manual pass is cheaper than standing up tooling, rule governance, and CI wiring.
• You need runtime functionality, not a dev tool. Rector is a development/CI dependency. It does not belong in production dependency trees; if the need is "transform data at runtime," re-scope the requirement.
• You have no test safety net and no appetite to build one. Either sequence tests first or restrict Rector to low-risk rule subsets.
• Your transformations are semantic and design-level — architecture changes, domain model reshaping, concurrency fixes. Rector handles mechanical, syntactic class of change; it will not decide your bounded contexts.
• You're evaluating rector-src specifically as an installable package. Stop; use the distribution repo. Also note the low star count and zero dependents here are artifacts of it being a source mirror, not a signal of immaturity — but they do mean you should not cite this record as market validation.
• Your stack is polyglot and PHP is a minority. A PHP-only codemod engine solves a slice of the problem; don't let it anchor a "we automate all migrations" narrative.

How to Pitch It (Stakeholders)

For executives — one paragraph. A large share of what we call "upgrade work" is mechanical: the same rename, the same signature change, the same deprecated call, repeated across thousands of files. Rector automates that class of change for PHP, applying version- and framework-aware rules and producing an ordinary pull request for review. The business case is not developer convenience; it is compressing the calendar time and headcount on runtime and framework upgrades, which are otherwise the recurring tax that keeps us off supported versions. The investment is small and bounded — a dev dependency plus rule authoring — and it is MIT-licensed with no vendor lock-in. The risk is equally bounded: changes land as reviewable diffs, gated by our test suite, and are revertible like any other commit.

For engineering leadership — the shape of the bet. Adopt the distribution package (rectorphp/rector), not the -src development repo. Start with a pilot on one non-critical service: run a dry-run against a target PHP/framework version, measure the automatable fraction of the diff, and record the review burden per file. That single number decides everything downstream. If the automatable fraction is high and review burden is low, productize: a shared rule set, a CI dry-run gate to freeze new debt, and a scheduled upgrade cadence. If the fraction is low, you've spent two weeks to learn that your upgrade is genuinely design work — which is itself a decision-grade finding.

Sequencing that makes the pitch credible.

1. Pilot one repo, one version hop, dry-run only, no merges. Output: automatable %, review hours, rules that needed hand-writing.
2. Gate the pilot repo in CI (--dry-run failing on new violations) so the debt stops growing while you decide.
3. Scale to a second and third repo only after the pilot's review-burden number holds. Publish the shared rule set as an internal package.
4. Institutionalize a rule owner — a named person or small team accountable for the rule set. Unowned codemod infrastructure rots faster than the code it was meant to fix.

What to promise and what not to. Promise: fewer hand-edited files, a repeatable upgrade path, reviewable diffs, no license cost, and a ruleset that compounds in value across future upgrades. Do not promise "upgrades become free," "no human review," or "it handles architecture." Frame it honestly as leverage on the mechanical 60–80% of a migration, with the judgment-heavy remainder unchanged — that framing survives contact with reality, and the inflated one destroys the program's credibility on the first release that needs real engineering.

Ask. A timeboxed pilot (roughly 2–3 engineer-weeks including test-coverage assessment on the pilot repo) plus a decision checkpoint against two numbers: automatable-diff percentage and review hours per 1,000 changed lines. Approve scale-out only if both beat the manual baseline.