Weave Code
Rector Rules Laravel Package
ergebnis/rector-rules
A Composer package of Rector rules for PHP projects, including sorters for associative arrays and match arms, removal of named arguments for single parameters, Faker generator property-to-method conversion, relative namespaced symbol references, and PHPUnit test attribute replacement. Install with c...
Provides rules for rector/rector.
Frequently asked questions about Rector Rules
- How do I install ergebnis/rector-rules in a Laravel application?
- Install it as a dev dependency with composer require --dev ergebnis/rector-rules, then register the rules you want in your project's rector.php ruleset. It ships no service providers, facades, or publishable config, so there is nothing to wire into the application itself. Run vendor/bin/rector process --dry-run first to review the diffs before applying changes.
- Is ergebnis/rector-rules compatible with Laravel and rector-laravel?
- Yes. Each rule is an AbstractRector subclass, so it runs inside the same Rector pipeline you already use on a Laravel codebase. The package is framework-agnostic and complements driftingly/rector-laravel rather than replacing it. Only the Faker and PHPUnit rules intersect with conventions Laravel teams commonly care about.
- Which version of rector/rector does ergebnis/rector-rules require?
- The package currently pins rector/rector to ^2.1.3, and earlier releases used constraints such as ^1.0.0, ^2.0.0, and ^2.0.11. Check that your project's Rector constraint, including any rector-laravel extension, satisfies that range before adding the package. Because Rector's major releases are frequent and the rule API moves, Composer conflicts are the most common installation failure here.
- Which rules does ergebnis/rector-rules provide?
- Six rules are available: SortAssociativeArrayByKeyRector, RemoveNamedArgumentForSingleParameterRector, SortMatchArmsByConditionalRector, GeneratorPropertyFetchToMethodCallRector for Faker calls, ReferenceNamespacedSymbolsRelativeToNamespacePrefixRector, and ReplaceTestAttributeWithTestPrefixRector for PHPUnit. Each rule has its own documentation page with a diff example. You register them individually, so you can adopt only the ones that match your team's conventions.
- Are the sorting rules safe to run on production code?
- SortAssociativeArrayByKeyRector and SortMatchArmsByConditionalRector preserve value semantics but not necessarily order semantics. Reordering keys is fine for key-lookup consumers but risky for code that depends on insertion order, such as serialization, config precedence, fixture builders, and snapshot assertions. Reordering match arms also changes the review surface and can interact with side-effecting conditionals. Run them on a branch and review the diffs before enforcing them in CI.
- What does ReferenceNamespacedSymbolsRelativeToNamespacePrefixRector do and should I enable it?
- It rewrites imported and partially qualified symbol references so they are relative to a configured namespace prefix, with namespace-prefix discovery and a forceRelativeReferences option. Its changelog shows several consecutive bug fixes, which suggests edge-case density. Enable it only if your namespace layout actually benefits from prefix-relative references, and review the resulting diff for churn before committing.
- How do I configure a single rule, like the comparison function for SortAssociativeArrayByKeyRector?
- Each rule is configurable through Rector's standard configure() mechanism in rector.php. SortAssociativeArrayByKeyRector accepts a comparison function for ordering keys, while ReferenceNamespacedSymbolsRelativeToNamespacePrefixRector exposes namespace-prefix discovery and forceRelativeReferences. Adopt one rule at a time with a --dry-run pass, then add the next once the diff is clean.
- How do I test ergebnis/rector-rules before applying changes in CI?
- Register the rules in rector.php, run vendor/bin/rector process --dry-run, and inspect the generated diffs before letting Rector write anything. In CI, run the rules as a check rather than an auto-fix so unexpected transformations fail the build instead of silently landing. Commit each rule adoption separately so reviewers can attribute behavior changes and bisect regressions.
- How do I handle deprecated or renamed rule classes when upgrading?
- Rule classes have moved namespaces and been deprecated across releases, for example Arrays\SortAssociativeArrayByKeyRector became Expressions\Arrays\SortAssociativeArrayByKeyRector. Track the changelog aliases when you bump the version, and update the class names in rector.php at the same time. Using the old class name after an upgrade typically fails with a missing-class error during the Rector run.
- Is ergebnis/rector-rules actively maintained and safe to rely on?
- The project health signals are mixed. It has an active release cadence, a detailed changelog, per-rule documentation, a security policy, and an MIT license, but adoption is very small and the bus factor is effectively one maintainer. Support is explicitly limited and sponsorship-funded. Treat it as an optional convention layer in require-dev that you can remove from composer.json and rector.php if maintenance stalls.
Weaver
How can I help you explore Laravel packages today?