Rector Laravel Laravel Package

Product Decisions This Supports

• Committing to a Laravel major upgrade on the roadmap. withComposerBased(laravel: true) auto-detects the installed Laravel (and Faker, Livewire, Cashier) versions and applies only the rules relevant to the target version. This converts "upgrade Laravel 11 → 13" from an unbounded, un-estimable epic into a bounded, scriptable workstream you can put a date against.
• Build vs. buy for internal codemod tooling. Do not build your own migration rewriter. This is the community-maintained, MIT-licensed rule layer on top of Rector, with version-scoped sets and first-party package coverage. The buy decision is a composer require --dev.
• Tech-debt budget allocation. The additional sets (LARAVEL_CODE_QUALITY, LARAVEL_TYPE_DECLARATIONS, LARAVEL_STATIC_TO_INJECTION, LARAVEL_TESTING) are opt-in quality levers. A "modernization sprint" can be scoped as a discrete deliverable with a diff to show for it, rather than perpetual, invisible refactoring.
• Framework-support policy and EOL planning. If the policy is "stay within one major of latest Laravel," this is the tool that makes the policy affordable. If the upgrade can't be funded, this quantifies what the policy costs in engineer-days instead of hand-waving.
• Legacy modernization and onboarding use cases. LARAVEL_LEGACY_FACTORIES_TO_CLASSES and LARAVEL_FACADE_ALIASES_TO_FULL_NAMES are concrete, low-risk wins on inherited codebases — good first-ticket work for new hires and a visible early win.
• Standardization across a portfolio of apps. Rules are deterministic and diff-producing, which makes this a governance mechanism: the same transformation applied to every service, reviewable in PRs, instead of ten teams each doing it a different way.

When to Consider This Package

Adopt when:

• A Laravel major version bump is planned (or one was skipped) — the composer-based set makes the target version the only input.
• The codebase is large or long-lived, so manual upgrade effort scales with code volume rather than with the number of actual breaking changes.
• CI exists with a test suite you trust. Rector rewrites code; the tests are the safety net. No tests, no automated rewriting.
• You want repeatable, reviewable codemods as an engineering standard rather than one-off heroics.
• The team is comfortable with dev-tooling configuration (rector.php, dry-run, then apply, set by set).

Look elsewhere or de-scope when:

• Greenfield or small app — manual fixes are cheaper than setup plus diff review.
• The transformation you need isn't covered. Check the rule overview and Rector's Find Rule first; uncovered changes remain manual regardless.
• The codebase is heavily customized against framework internals (overridden facades, macros, custom container bindings). Rules like LARAVEL_STATIC_TO_INJECTION and LARAVEL_ELOQUENT_MAGIC_METHOD_TO_QUERY_BUILDER are opinionated and may change readability or behavior in ways the team rejects.
• You need vendor support or an SLA — this is community-maintained under MIT. Treat it as a dependency with normal open-source risk and a single-maintainer bus factor.
• You cannot absorb a large mechanical diff during a release freeze. Run it at the start of an upgrade cycle, not the end.

On the signals: 1.3k stars and a steady release cadence indicate real adoption. The "0 dependents" figure reflects that this is installed as a dev dependency only — it does not mean unused. Validate against your org's own usage, not that number.

How to Pitch It (Stakeholders)

For executives: Our Laravel version determines our security posture and access to framework improvements, but major upgrades are the kind of project that slips a quarter because the work is manual and hard to estimate. This package automates the mechanical portion: it reads composer.json, applies every transformation relevant to our target version, and produces reviewable pull requests. It is MIT-licensed, free, and installed as a dev-only dependency that never ships to production. The ask is engineering time to run it behind our test suite — not budget.

For engineering leadership and the team:

• Risk is bounded by our tests, not by trust in the tool. Workflow: enable, run in dry-run, read the diff, apply one set at a time. Never a single big-bang rewrite.
• Start with the version set only via withComposerBased(laravel: true). Add quality sets (LARAVEL_TYPE_DECLARATIONS, LARAVEL_CODE_QUALITY) as deliberate, separately reviewed initiatives — never bundled into an upgrade PR.
• Stay conservative on rule selection. Opinionated rules (ResponseHelperCallToJsonResponseRector, EmptyToBlankAndFilledFuncRector, LARAVEL_STATIC_TO_INJECTION) are opt-in for a reason: they change style and sometimes semantics.
• A few configurable rules need a team decision, not a default: RouteActionCallableRector (helps IDE and static analysis), WhereToWhereLikeRector (depends on our DB driver), and RemoveDumpDataDeadCodeRector (a good permanent guardrail).
• Ongoing cost is a dev dependency plus CI minutes, refreshed once per upgrade cycle.
• Success measures: engineer-days per upgrade cycle, size of the hand-written migration diff, and lead time from "Laravel X released" to "we are on X."