Rector Generator Laravel Package

Technical Evaluation

Architecture fit — rector/rector-generator is a development-time code-generation tool, not a runtime dependency. It scaffolds a PHP class implementing Rector's rule contract (plus a fixture/test stub) so a developer can start writing a custom refactoring rule without hand-rolling boilerplate. For a Laravel codebase it belongs strictly in require-dev, alongside rector/rector, Pint, and PHPStan/Larastan. Its architectural fit is therefore conditional: it is useful only if Rector is already a first-class part of the upgrade pipeline. If Rector isn't there, this package contributes nothing.

Integration feasibility — Composer-installable in isolation, but the distribution signals are disqualifying for new work: it lives under the deprecated-packages namespace, has zero stars and zero dependents. Installation is technically trivial; the practical problem is that you are adopting a frozen snapshot with no upstream. Worse, its entire output is version-coupled — generated stubs target a specific Rector API surface (AbstractRector method signatures, getRuleDefinition() return shapes, RuleDefinition constructor arity), and those have moved repeatedly across Rector majors. The generator will cheerfully emit classes that no longer compile against a modern Rector.

Technical risk — High relative to a very small payoff:

• API drift: generated stubs decay silently as Rector evolves, with no upstream fix path.
• Lockfile entanglement: a pinned abandoned dev dependency can block composer update of Rector, PHPUnit, or PHPStan, which cascades into blocked framework upgrades — the exact thing Rector exists to prevent.
• Superseded functionality: Rector core now bundles its own rule-generation command (naming varies by version), so this package duplicates a maintained feature with an unmaintained one.
• Explicit abandonment signal: the namespace plus Composer's abandoned flag is the ecosystem telling you not to build on it.

Key questions — Is Rector in the pipeline today, and pinned to which major? Do we actually need custom rules, or do community rule sets cover the Laravel/PHP migration in scope? Who owns upgrade automation as a standing responsibility? Can the pinned Rector version's built-in generator produce an equivalent scaffold?

Integration Approach

Stack fit — The natural home is the dev-tooling layer: Composer scripts, a rector.php config, and a CI job that runs Rector in --dry-run on pull requests. The generator touches only the authoring workflow, never CI runtime, so the blast radius of trying it is small — which is precisely why the decision should be made on maintenance grounds rather than risk grounds.

Migration path — Don't migrate to this package; migrate away from the need for it:

1. Pin rector/rector to a supported major and use its bundled rule-generation command.
2. If a scaffold is genuinely wanted, copy the generated class shape into an internal stubs/ or tools/ directory once and own those ~30 lines. That artifact is cheaper than any dependency.
3. If a team already depends on it, remove it in the same pull request as the Rector upgrade — never across separate releases, or the lockfile will strand you between incompatible versions.

Compatibility — Validate against the team's PHP floor and Laravel's PHP constraint before adding anything; run composer why-not rector/rector <version> to see whether the generator's constraints block the Rector version you actually want. Assume no PHP 8.4/8.5 readiness and no Laravel-version-specific fixes, because there is no maintainer to ship them.

Sequencing — (a) Get Rector running in dry-run mode in CI, (b) hand-author one or two rules to prove the value of custom rules for your codebase, (c) only then evaluate whether scaffolding tooling is worth any dependency. Doing (c) before (b) inverts the value chain and buys ceremony instead of migrations.

Operational Impact

Maintenance — Effectively zero upstream maintenance; anything adopted becomes your code to patch. Deprecation means the vendor explicitly will not triage issues. Either budget named ownership for a fork, or skip it.

Support — No maintainers, no security advisories, no CVE response. The runtime security surface is small (it writes files at CLI invocation), but supply-chain exposure is not zero: unmaintained Composer packages are a recurring vector, and composer audit will keep surfacing it in reports that someone then has to triage every sprint.

Scaling — This tool doesn't scale with traffic; it scales with headcount. One developer learning a scaffold is cheap. Mandating it as a workflow across several squads means N engineers depending on an unmaintained binary and N sets of stale local instructions. The genuine scaling lever is the rule set committed in your repo — that asset persists regardless of which generator produced the first class.

Failure modes — Generated class fails to parse or type-check against a newer Rector major; generator writes to an unexpected path and overwrites an existing rule; version constraint blocks a security update elsewhere in the lockfile; onboarding docs reference a command that no longer exists upstream.

Ramp-up — Low for the tool itself (under an hour). Materially higher for Rector's actual mental model — node visitors, NodeFactory, scope handling, fixture-based rule testing — which is days, not hours, before a developer writes rules worth keeping. The generator does not meaningfully shorten that curve; it only saves typing a class skeleton once.

Recommendation — Do not adopt. Use the rule generator bundled with your pinned Rector version, or template the class internally. Given zero stars, zero dependents, a deprecation namespace, and a superseded feature set, rector/rector-generator is best treated as a reference for the pattern of scaffolding Rector rules, not as a dependency in a Laravel stack.