Rector Config Laravel Package

Technical Evaluation

Architecture fit. stickee/rector-config is a dev-tooling package, not a runtime dependency. It provides a shared Rector configuration preset — rules, paths, and PHP/Laravel version targets — that a project's own rector.php can extend. That places it squarely in the CI/static-analysis layer of a Laravel stack: zero production footprint, no autoloading concerns, no service provider implications. Architecturally it's about as low-risk as adoption gets, because it never ships to users.

Integration feasibility. Integration is a composer require --dev plus a one-line extends (or config import) in rector.php. For a team already running Rector for framework upgrades or automated refactors, this is hours of work, not sprints. The value proposition is consistency: one canonical rule set across repositories instead of each project drifting its own config.

Technical risk. The blast radius is small (dev-only, reversible by removing the dependency), but the sustainability risk is material. Zero stars, zero dependents, and a single-org origin mean no community backstop. Risks to flag:

• Upstream coupling. Rector has a fast-moving API and frequent major versions. A thin config package can silently lag or break against a newer Rector. Check the require constraints before committing.
• Opinionation mismatch. Stickee's rules encode their standards (strictness level, Laravel idioms, test conventions). Adopting it wholesale imports someone else's house style.
• Abandonment. With no dependents, there is no crowd testing the upgrade path. If Stickee stops publishing, you inherit a fork.

Key questions.

1. Which Rector major version(s) does it support, and what is its PHP/Laravel version floor and ceiling?
2. Does it bundle framework-specific rule sets (Laravel, PHPUnit, dead-code, type-declaration) or only generic rules?
3. How does its strictness compare to our current rector.php — will it generate a large, noisy one-time diff?
4. Is the repo actively maintained (commit cadence, release hygiene, issue responsiveness)?
5. Are we comfortable treating an external org's standards as ours, or do we only want a subset of its rules?

Given the 0.2 score and 39.32 opportunity, the honest framing to stakeholders is evaluate, don't adopt blindly — the upside is real but modest, and the sustainability profile is thin.

Integration Approach

Stack fit. Assumes Composer-managed PHP 8.x with Rector already (or about to be) in the dev toolchain, and a CI runner capable of executing Rector in dry-run mode. Fits GitHub Actions/GitLab CI cleanly because it adds no runtime services or secrets.

Migration path.

1. Inspect first. Read the package's config source to enumerate the rule sets and version constraints. Do this before any install — it is the single highest-information step.
2. Pilot on one non-critical repo. Install as require-dev, extend the preset, run rector --dry-run, and capture the diff volume.
3. Diff-triage. Classify changes as desired (upgrade-safe refactors) vs. unwanted (style churn). Prune rules via local overrides rather than forking.
4. Baseline commit. Apply the accepted refactors in a single dedicated PR so the change is reviewable and revertible.
5. Enforce. Add a CI step running Rector in --dry-run and failing on new violations, starting advisory and later blocking.

Compatibility. Pin the package version exactly in composer.json (config packages are cheap to pin) and let Renovate/Dependabot surface upgrades alongside Rector upgrades, so the pair moves in lockstep. Verify the package's rector/rector constraint against whatever version your upgrade program requires. If the constraints conflict, that is a decisive signal to wrap the rules locally instead.

Sequencing. Treat this as a standardization enabler, not an upgrade driver. It pays off only if you already have (or plan) a Rector-based modernization effort — e.g., a Laravel or PHP-version upgrade. Adopting it standalone, with no upgrade roadmap behind it, yields little. Best sequence: confirm the upgrade program → pilot the config → standardize → enforce in CI.

Build-vs-adopt contingency. If inspection reveals the config is mostly generic rules plus a few Laravel-specific ones, the pragmatic answer is to author a short internal preset (30–60 lines) and own it. The external package only wins if it carries genuinely non-trivial curated rule knowledge.

Operational Impact

Maintenance. Near-zero ongoing effort if the package tracks Rector releases. The maintenance burden shifts to version pairing: every Rector bump is a potential config-compatibility event. Budget a standing quarterly check rather than assuming it is "set and forget."

Support. There is no community, no dependent ecosystem, and no vendor SLA. Support is effectively self-support: your platform team owns diagnosing breakage. If this becomes a standard across many repos, name an explicit owner — an unowned shared config is a latent trap.

Scaling. Scales technically: one more dev dependency and a CI step, cost roughly linear in repo count and proportional to codebase size per run. The scaling risk is organizational, not technical — a shared config that many teams depend on becomes a de-facto internal standard, and standards need governance (a change-review path, a deprecation policy, documented exceptions).

Failure modes.

• Silent drift: package stops being updated, Rector moves on, CI starts failing on the config itself. Mitigation: pin, monitor, and be ready to inline the rules.
• Over-aggressive refactor: a preset rule produces semantically risky changes. Mitigation: pilot with dry-run, review diffs, never auto-merge Rector output.
• Version lock conflict: package constrains Rector below what your upgrade needs. Mitigation: local override preset as escape hatch.
• Abandonment/fork: upstream disappears. Mitigation: MIT license permits vendoring the config into your repo — keep that exit cheap by not spreading the extends across dozens of repos without a replacement plan.

Ramp-up. Developer learning curve is mostly Rector, not this package — engineers need to understand what refactor rules do and how to review their output. Expect a short enablement session plus written guidance on overriding rules. TPM effort is front-loaded: assessment, pilot coordination, and defining the CI gate policy, after which operational load is light.

TPM recommendation. Frame this as a low-cost, low-commitment experiment with a defined exit. Pilot on one repo, measure diff noise and maintenance signal over a quarter, and hold a pre-agreed fallback: vendor the config internally. Do not standardize org-wide on a 0-star, 0-dependent package without that fallback in hand.