Rector Prefixed Laravel Package

Technical Evaluation

Architecture fit. rector/rector-prefixed is a distribution artifact, not an application library. Its only reason to exist is to let teams embed Rector's automated refactoring engine inside projects whose dependency graph would otherwise collide with Rector's own vendor tree — achieved by namespacing all internals under a unique prefix and downgrading the source to PHP 7.1. For a Laravel/PHP portfolio the fit is deliberately narrow: it is a dev-time/CI tool, never a runtime dependency, so production blast radius is near zero. As a TPM the relevant question is not "does it work" but "do we need a prefixed Rector in 2021-era form, and is there a maintained equivalent."

Integration feasibility. Technically installable from Packagist as a require-dev package, but the repository is archived and the last release is April 2021. Composer will surface it as abandoned. The engine, rule sets, and configuration format are frozen at that snapshot. Feasibility for new adoption is effectively zero; it is only defensible as a pinned artifact in a legacy PHP 7.1–7.x environment where offline refactoring is genuinely required. With 0 dependents there is no ecosystem validation to lean on.

Technical risk. High on the axes that matter for tooling: no security patching, no PHP 8.1+ compatibility, no upstream bug fixes, and a growing semantic gap between this snapshot and current Rector documentation. Supply-chain risk is muted but real — the GitHub source is archived while the Packagist artifact remains resolvable, so availability depends on registry retention. The dominant risk is not exploitability (it never ships) but unreproducible developer workflow: a CI job that silently depends on an unmaintained artifact and breaks when the toolchain moves.

Key questions.

• Do we actually need the prefixed variant, or will a Rector PHAR (or the modern, self-contained rector/rector) satisfy the same requirement?
• Which PHP versions are in scope for the consuming repos?
• Is there an internal owner willing to fork and patch, or is this disposable?
• What is the exit plan and timeline if we adopt it?

Integration Approach

Stack fit. Assume require-dev only, scoped to a CI container or a local refactoring image. It should never enter a production build target or a Laravel runtime image. There is no framework integration surface — it is a CLI that reads and rewrites PHP source.

Migration path. Modern rector/rector is itself distributed as a self-contained/prefixed tooling package, which is precisely why this repo was deprecated. Migration is therefore an upgrade and a compatibility jump: config moves to rector.php, rule class names and set lists change, and PHP constraints shift upward. Treat migration as a standalone modernization workstream rather than a drop-in swap.

Compatibility. PHP 7.1+ by construction (downgraded), so it will not run on PHP 8.1+. Composer 2 resolves it but emits abandoned-package warnings. Prefixed internals can shadow classes in unusual ways if the consuming project also loads those namespaces — generally safe, but worth validating in the specific repo.

Sequencing.

1. Inventory: grep the portfolio for rector-prefixed in composer.json/lockfiles to establish real footprint.
2. If present, pin to the exact locked version and isolate execution in a container image so the PHP version is controlled.
3. Use it only for one-off or bounded refactoring runs; do not build new automation on top of it.
4. In parallel, stand up current rector/rector (or the PHAR) in the same repo for a diff-based validation, then cut over.
5. Remove the dependency and add a policy note that archived dev tooling requires an exception.

Operational Impact

Maintenance. Zero upstream maintenance. Ownership must be internal and explicit, or the dependency must be treated as disposable and removed on a schedule. There is no CVE feed, no advisory monitoring, and no patch path other than a local fork.

Support. No community, no dependents, no issue triage. Support burden is entirely internal and disproportionate to the tool's value. Engineers debugging failures will find upstream docs describing behavior from a newer Rector than the one they are running, which is a persistent source of wasted cycles.

Scaling. Scaling here is not about traffic — it is about repo count and CI minutes. Running refactors across many Laravel repos is CPU-bound and parallelizable, but this snapshot misses the performance work landed in later Rector releases, so cost per repo will be higher than a current toolchain.

Failure modes.

• Composer install fails or hard-errors once PHP on the runner is upgraded.
• Abandoned-package warnings break CI quality gates.
• Rule behavior diverges from documented Rector, producing incorrect refactors that pass review.
• Artifact becomes unavailable or unverifiable after cache eviction, making historical runs unreproducible.
• Silent drift between what the prefixed build supports and what the migration plan assumes.

Ramp-up. Low technical ramp (it is a CLI with a finite command surface), but high knowledge ramp because the documentation lag forces engineers to reverse-engineer the snapshot. Budget for documentation translation and for the eventual migration; do not staff this as a quick utility adoption.