Rector Config Laravel Package

Technical Evaluation

What this actually is. wyrihaximus/rector-config is not a library with an API. It is a personal configuration distribution for Rector: a set of opinionated defaults plus a handful of custom rules the author applies to his own repositories. Its value is entirely derivative of Rector being present. If we are not already running Rector, the package is not the adoption decision; a Rector rollout is, and this package rides along at near-zero marginal cost. If we are running Rector, this is a thin, unvalidated layer on top of defaults we could write ourselves in under a day.

Architecture fit. Low coupling, low blast radius. Rector is a dev-time AST refactoring tool, so nothing here ships to production, participates in the request path, or affects autoloading at runtime. That materially lowers the stakes of every risk below. The trade-off is that the same property makes the package non-critical: it competes against a hand-rolled internal preset that we control.

Integration feasibility. Trivially feasible. composer require --dev, then one line in rector.php to register the set. The real integration questions are constraint questions, not effort questions: which Rector major it targets, its PHP floor, and whether its rules assume specific PHPUnit or async-stack versions. The set registration is effectively a private API surface with no compatibility contract, so any upgrade of either side is a manual verification event.

Technical risk. The dominant risk is provenance, not code quality.

• Zero stars and zero dependents means zero independent verification. Nobody has run these rules against a codebase unlike the author's, so false positives are undiscovered rather than absent.
• Single maintainer, no vendor, no support path. Abandonment is a matter of when, not if.
• The custom rules encode one person's style preferences against his own async/event-loop-heavy stack. They may be correct and still be wrong for us.
• Data quality flag: the release is dated 2026-08-08. Treat "recent release" as unverified until confirmed, and do not let it stand in for a maintenance commitment.

Signals in favor, and why they do not flip the decision. MIT license, published releases, a README. More substantively, the author's documented engineering bar is unusually high: PHPUnit with 100% coverage, 100% MSI via Infection, 100% PHPStan type coverage, dataprovider-first tests. That is a stricter internal standard than many commercially backed projects hold, and the author is a long-standing PHP OSS contributor, which reduces but does not eliminate abandonment risk. The 16.8 composite against a 63.9 opportunity score is best read as "useful if it matured and someone adopted it first." That is an argument for watching the package, not for volunteering to be dependent zero.

Key questions.

1. Which of its rules actually fire on our codebase, and how many produce false positives on a dry run?
2. Does it declare its dependencies under require-dev only, or does it drag runtime dependencies into our graph?
3. What is its supported Rector version window, and what is the historical lag after each Rector major?
4. Is there a documented security policy and a release cadence, or is the release date above an artifact?
5. Are any of its rules load-bearing for codemods we cannot reproduce ourselves?
6. Who on our side owns the Rector toolchain, and would they rather maintain a fork than a dependency?

Integration Approach

Stack fit. Position it strictly as a dev dependency in the lint/static-analysis tier of CI, alongside PHPStan and PHP-CS-Fixer. Verify at install time that it contributes nothing to the production autoload graph and nothing to the runtime dependency tree. If it does, that is a stop condition, not a trade-off.

Sequencing. Do not adopt across repositories. Run a four-step pilot:

1. Inventory. Run it in dry-run mode against one medium-sized, actively maintained repo. Capture the rule hit list and diff volume. This is the only measurement that determines whether the package has value for us.
2. Canary. Enable it as an advisory, non-blocking CI job on that repo for several weeks. Collect false positives as baseline entries.
3. Wrap. Do not reference the third-party set directly from application repos. Publish an internal preset (our-org/rector-preset) that includes this package and curates the rule list. Application repos depend only on the internal preset.
4. Promote. Expand repository by repository, and only after the internal preset has survived one Rector minor upgrade without incident.

Compatibility. Pin exactly in composer.lock. Add an explicit Rector version constraint alongside it so a Rector bump forces a conscious upgrade rather than a silent mismatch. Check the PHP floor against our minimum supported version before anything else; a floor above ours ends the evaluation immediately. If any rules target PHPUnit, verify the supported PHPUnit majors against what we run.

Migration path and exit. The wrapper preset in step 3 is the exit strategy, not just hygiene. Removing the dependency should be a one-line change in one repository. For any rule we come to rely on for real codemods, vendor the rule into our own preset rather than depending on an unmaintained package for it. The implementation cost of a Rector rule is small; the cost of being unable to reproduce one is not. Assume a fork is the end state and price the pilot accordingly.

What not to do. Do not add it to a shared boilerplate or scaffold yet. Do not make it a merge gate during the pilot. Do not adopt it because the author's QA standards are impressive; those standards protect his code, not our upgrade path.

Operational Impact

Maintenance. Two dependency surfaces instead of one. Rector itself is the expensive one, with a history of breaking changes between majors; this package adds a lag vector on top, where a Rector upgrade is blocked until the config package catches up. Budget a small recurring cost and name an owner. The good news is the cost is bounded and the failure is loud.

Support. No vendor, no SLA, no escalation. The response path is a volunteer's GitHub issue tracker. That is acceptable only because the package is dev-only and optional. If it ever becomes load-bearing for a scheduled codemod across many repos, that calculus changes and the fork becomes mandatory.

Scaling. Technically free: adding a repository is one line in a preset. Organizationally not free. Every opinionated rule that fires across N repositories generates N cleanup pull requests and N review conversations. The binding constraint is reviewer attention, not runtime or license cost. Keep the enabled rule list short and justified per rule.

Failure modes.

• Upstream drift. A Rector major lands, the package lags, CI pin freezes us on an old Rector while the rest of the ecosystem moves. Detectable, recoverable, mildly annoying.
• Misfire. A rule rewrites code incorrectly across many files. Mitigated by dry-run-first, PR review, and never enabling auto-apply on a schedule without a diff gate.
• Abandonment. No maintainer, no patches, security issues unaddressed. Mitigated by exact pinning, the wrapper preset, and a pre-agreed vendor-in-house threshold.
• Supply chain. Dev dependencies still execute code in CI. A zero-dependent package has had little independent scrutiny. Install in an isolated job, run composer audit, avoid --no-scripts only if the package genuinely requires scripts, and keep CI token permissions minimal.
• Contributing back is expensive. The author's build system is a containerized Makefile chain inherited from wyrihaximus/makefiles, gated at 100% mutation score and 100% type coverage. Matching that bar to land a fix upstream is a real cost; assume we will patch our own fork instead.

Ramp-up. Near zero for consumers: one include line and a dry run. High for contributors: an unfamiliar Makefile-driven, mutation-tested workflow to satisfy before a patch is mergeable. Plan for consumption, not contribution.

Recommendation. Conditional pilot. Adopt as a bounded, dev-only, opt-in set on one or two repositories behind an internal preset, measured by dry-run diff volume, with a documented fork-in-place plan and a re-evaluation at the next Rector major. Do not standardize, do not gate merges on it, and do not treat the high internal QA bar of the upstream project as a substitute for a support commitment it does not have. Estimated effort: one to two engineer-days to reach a go/no-go.