Rector Rules Laravel Package

Product Decisions This Supports

• Upgrade/migration roadmap planning: The 1.9.2 addition of RenameStaticMethodRector for Str UUID static methods turns a manual, error-prone sweep across the codebase into a repeatable automated codemod. This directly de-risks Laravel major-version upgrades and UUID-strategy changes (e.g. moving from Str::uuid()/orderedUuid() toward UUIDv7-style APIs), letting you commit to a framework upgrade date with confidence rather than padding the estimate for hand-editing.
• Build vs. buy for internal tooling: Rather than staffing a "developer productivity / codemod" workstream, this package supplies maintained, versioned rules — each rule is a discrete feature you can adopt à la carte. The 1.9.x cadence (1.9.1 → 1.9.2 in a single rule-sized increment) is evidence of low-friction, continuous delivery of refactoring coverage.
• Technical-debt paydown as a product input: Because rules are mechanical and auditable, "reduce legacy patterns by X%" becomes a trackable, defensible metric in a quarterly roadmap rather than a vague engineering aspiration.
• Scoping feature work: Codebase-wide API modernisation (string/UUID helpers, static call sites) can be scheduled as a bounded, low-risk ticket instead of an unbounded research spike — useful when deciding whether a feature ships with or after an upgrade.
• Standardisation across teams: A shared rule set means one definition of "modern" for all Laravel services, which matters when you're deciding whether to consolidate multiple codebases onto a common platform baseline.

When to Consider This Package

Adopt when:

• You maintain one or more Laravel/PHP codebases on a known Rector version and have a repeatable path to run automated refactors in CI or on a branch.
• You have an upcoming framework or helper-API migration (like the Str UUID changes covered in 1.9.2) where manual edits would touch many files.
• You already use Rector in your toolchain; this package is additive rules, not a new platform.
• You want auditable, reviewable diffs — Rector output is a PR you can inspect, which suits teams with strict change control.
• You value incremental adoption: single-rule adoption is viable; you don't need to enable everything at once.

Look elsewhere when:

• Your stack is not Laravel-centric; the value concentrates in framework-specific rules.
• You don't run Rector and have no appetite to introduce it — the package is unusable standalone.
• You need guaranteed long-term support, SLAs, or vendor indemnity; this is a community package and 1.9.2 is a patch-level feature increment, so pin versions and review release notes per bump.
• Your codebase has heavy dynamic/metaprogrammed static calls that static analysis can't safely rewrite — expect partial coverage and manual follow-up.
• You're mid-freeze or on a release-locked branch where tooling churn is unwelcome; defer.

How to Pitch It (Stakeholders)

For executives: This is a low-cost developer-productivity dependency that converts risky, manual framework upgrades into automated, reviewable pull requests. The latest 1.9.2 release extends its coverage to Laravel's Str UUID helper methods — exactly the kind of small, recurring API drift that otherwise silently accumulates as technical debt. Cost is a Composer dependency; the return is shorter upgrade cycles and fewer upgrade-related regressions. No new platform, no vendor lock-in, no headcount.

For engineering: guanguans/rector-rules supplies Rector rules for Laravel/PHP refactoring. 1.9.2 adds RenameStaticMethodRector handling for Str-class UUID static methods, so UUID-helper migrations become a codemod instead of a grep-and-edit exercise. Recommend pinning to ^1.9, running new rules on a dedicated branch, and reviewing the resulting diff like any other PR. Treat each rule as opt-in: enable, verify against tests, keep or drop. Note this is a patch-level release carrying a new feature — pin exact versions and read release notes per bump rather than floating.