guanguans/rector-rules
A collection of custom Rector rules for PHP and Laravel projects that automates code refactoring, modernization, and upgrades. Register the rule sets in your rector.php config to enforce consistent standards and streamline migrations with less manual work.
Architecture fit. guanguans/rector-rules is a development-time tooling package, not a runtime dependency. It extends Rector with opinionated rules, so it slots into the build/CI layer alongside PHPStan, Pint, and PHPUnit rather than into application architecture. That makes it a low-coupling addition: it can be adopted by a single team, a single repository, or enforced org-wide without touching production code paths. Release 1.9.2 adds RenameStaticMethodRector for Str UUID handling, which is squarely in the package's established remit of automating Laravel-idiomatic refactors.
Integration feasibility. High. Adoption is a composer require --dev plus a rule registration in rector.php. The new rule is additive — 1.9.2 contains one feature commit and no breaking changes, removals, or deprecations — so the upgrade from 1.9.1 is a patch-level bump with no migration work. The main feasibility question is not "can we install it" but "do we want automated rewrites of Str::uuid*() call sites," which depends on whether the target codebase has already moved to the newer UUID API or is being prepared for it.
Technical risk. Low but non-zero. The class of risk here is refactoring correctness, not runtime instability: a Rector rule that misfires produces a bad commit, not an outage. Specific concerns are false positives on non-Laravel Str classes (or on aliased/imported Str), incomplete coverage of fully-qualified calls (\Illuminate\Support\Str::uuid()), and interaction with existing rules in the same set. Because the change is additive and opt-in by rule registration, exposure is bounded — teams that do not enable the rule are unaffected by 1.9.2.
Key questions.
composer.json?Str references, and does it skip non-Laravel Str classes?Stack fit. The package is a natural fit for any Laravel codebase already running Rector, and a reasonable first Rector introduction for teams that are not. It is a dev-only dependency with no production footprint, no service provider, and no config publishing required for basic use. For a Laravel 10/11 stack on PHP 8.2+ with Rector already in CI, the marginal integration cost is close to zero.
Migration path. Three steps: (1) add guanguans/rector-rules as a require-dev constraint pinned to ^1.9; (2) register RenameStaticMethodRector explicitly in the relevant rector.php set rather than adopting the package's full rule set wholesale; (3) run vendor/bin/rector process --dry-run across the repository and review the diff before applying. The dry-run diff is the actual migration artifact and should be reviewed by someone who knows the UUID call sites.
Compatibility. Verify the Rector constraint first — custom rules are tightly coupled to Rector's internal API and break across Rector majors. Confirm PHP version support against the oldest PHP in the supported matrix, and confirm no overlap with rules already configured (two rules rewriting the same node can produce order-dependent output). Because 1.9.2 is additive, upgrading from 1.9.1 in an existing installation requires no code changes and no config changes unless the new rule is deliberately enabled.
Sequencing. Recommend: pin and install in one pilot repository → enable the UUID rule in dry-run-only CI job → review findings and confirm rule correctness against the fixture → promote to a blocking CI check → roll out to remaining repositories. Do not bundle the rule enablement with an unrelated framework upgrade; keep the refactor commit isolated so it is revertible and reviewable. Hold org-wide enforcement until at least one full release cycle has passed without a false-positive report.
Maintenance. Ongoing cost is low: a pinned dev dependency, no runtime surface, no database or queue interaction. The real maintenance obligation is changelog surveillance — Rector-major upgrades in the host project will likely require a matching bump here, and the new rule may need revalidation when Laravel's UUID API evolves. Assign an owner for the dependency and review releases on a monthly cadence rather than per-release.
Support. This is community OSS with a narrow maintainer base. There is no vendor SLA, and issues are resolved on a best-effort basis. Mitigate by pinning exact versions, keeping the rule registration minimal, and being prepared to fork or vendor the single rule if upstream stalls. The rule is small enough that in-house ownership is a credible fallback.
Scaling. The tool scales with repository count, not traffic. Cost is CI wall-clock time on every run; on a large monorepo, Rector is typically the slowest static-analysis step. Scope the rule to relevant paths and cache Rector results where possible. Enabling additional rules from this package multiplies both runtime and review burden, so add them one at a time.
Failure modes. (1) Incorrect rewrite — a Str call renamed in a context where the old method was intentional; caught by diff review and tests, not by CI alone. (2) Silent miss — fully-qualified or aliased calls left untouched, giving a false sense of migration completeness; verify with a post-run grep. (3) Rule conflict — interaction with an existing rule producing unstable output across runs; detect by running Rector twice and diffing. (4) Version skew — a Rector major bump in the host project breaking the rule; surfaces as a CI failure, which is the safe direction. (5) Over-broad adoption — enabling the full package rule set at once, producing a large unreviewable diff.
Ramp-up. Minimal. Engineers already comfortable with Rector need only learn the specific rule's intent; engineers new to Rector need a short primer on dry-run, diffs, and rule config. Budget roughly half a day for the pilot repository including review, and treat the first dry-run diff as the training material.
Release-specific note (1.9.2). Additive feature, no breaking changes, no deprecations. It does not force an upgrade for existing adopters. The decision it informs is whether to enable the new UUID rule, not whether to install the release — those should be treated as separate approvals, with enablement gated on the dry-run review described above.
How can I help you explore Laravel packages today?