Product Decisions This Supports
- PHP upgrade and modernization roadmaps. Rector automates mechanical refactors (PHP version bumps, deprecated API swaps, dead code removal). This package is the configuration and rule layer on top of it. The PM decision it informs is: how much of an upgrade campaign do we automate versus staff manually, and what is the cost per major-version bump across N services.
- Tooling standardization across a PHP portfolio. If you run many services or packages, the real choice is between (a) a pinned shared dev-dependency, (b) a copy-pasted
rector.php in every repo, or (c) an internally owned rule set. This package is a candidate for (a) and is a useful reference implementation for (c).
- Build vs buy for an internal refactoring/static-analysis platform. Comparing "fork this and own it" against "consume upstream and accept its cadence" against "write our own rules" is a scoping decision you can make cheaply because the artifact is small, MIT licensed, and dev-only.
- Codifying a style guide as executable rules. A judgment call that recurs on every team: prose conventions in a wiki versus rules enforced in CI. This package shows the shape of the latter and what maintenance burden it implies.
- CI cost and review-noise policy. Automated refactors generate large diffs. Whether to run them per-PR, per-scheduled-job, or only on upgrade branches is a real workflow decision, and the config surface here is what constrains that choice.
- Risk tiering of dependencies. This is a dev-only dependency with no production blast radius, which lets you set a materially higher risk tolerance than you would for a runtime package. That tiering decision is worth making explicit so engineering does not apply production-grade vendor scrutiny to a linter.
When to Consider This Package
Consider it when all of the following hold:
- You already use Rector or have decided to adopt it; this package is not useful standalone.
- Your codebase and conventions are close to the author's (WyriHaximus packages, PSR-heavy, strict typing, high coverage and mutation-testing standards). The rules encode opinions, not neutral defaults.
- Your dependency policy tolerates single-maintainer dev dependencies, or you are willing to fork and vendor the rules internally.
- You want a working example of Rector config wiring more than you want a supported product.
Look elsewhere when any of the following apply:
- You need a battle-tested or supported dependency. Zero stars and zero dependents is the headline finding. There is no downstream usage to serve as evidence of correctness, and no signal that breakage would be noticed quickly. For infrastructure you intend to rely on across many repos, that is a disqualifier on its own.
- The documentation you were given is not consumer documentation. The surfaced "docs" are the maintainer's agent and CI instructions (
make install, forbidden commands, Makefile ownership, test-coverage policy). Useful for contributors inside that repo; it tells a prospective adopter nothing about installation, configuration, or which rules ship. Treat onboarding cost as unknown and unbounded.
- You are on Laravel specifically. The community Laravel Rector rule set is the mature, widely adopted option and covers framework-specific refactors this package will not.
- You want vendor or foundation backing. MIT plus a recent release is not a support contract. If your organization requires a maintenance commitment, named owners, or a security response process, none of that is present here.
- Your primary need is formatting or static analysis rather than refactoring. PHP-CS-Fixer, Laravel Pint, and PHPStan at the appropriate level solve different problems and have far deeper adoption.
- Naming and packaging ambiguity is a blocker. The repository is named
rectorphp-config while the Composer package is wyrihaximus/rector-config. Minor, but resolve it before adding to any approved-dependency list, and verify the release dates, one of which reads as a future date and should be confirmed against Packagist.
Net recommendation: do not adopt as a platform dependency. Use it as a time-boxed spike or as a reading reference when designing your own Rector configuration. The cost of evaluating it is hours; the cost of depending on it is unbounded.
How to Pitch It (Stakeholders)
To executives: This is a small, free, MIT-licensed developer tool in the automated-refactoring space, not a platform bet. Its value is cost avoidance on PHP upgrade work, and its risk is capped because it never ships to production. Recommendation is a short, bounded evaluation, not adoption. Expect no line-item savings unless we are also committing to an upgrade campaign, in which case the savings show up as reduced engineering hours per service, not as a line item from this package.
To engineering: It packages Rector configuration and some extra rules. The upside is that it saves you writing config from scratch and gives you a concrete example of the author's conventions. The downside is honest: zero stars, zero dependents, one maintainer, and the available documentation is repo-internal contributor guidance rather than user docs. Treat it as a pattern to borrow, or fork it and own the rules internally. If we standardize on Rector tooling, the deliverable is our own pinned, tested config, with this repository as one input, and the framework-specific community rule sets as the others.