Rector Config Laravel Package

Technical Evaluation

What this actually is. serendipity_hq/rector-config is not a library — it is a published snapshot of one agency's internal Rector configuration. Rector is a PHP AST-based refactoring/automated-upgrade tool; a "config package" typically exposes one or more set files (PHP scripts returning a RectorConfig closure) so other projects can ->withSets() them. There is no runtime API, no service, no reusable domain logic. The deliverable is opinion, encoded as PHP.

Architecture fit. Fit is narrow and conditional: it only makes sense if the consuming project is (a) PHP, (b) already running Rector in CI or locally, and (c) willing to inherit Serendipity HQ's coding-standard opinions wholesale. In practice Rector configuration is a 30–80 line file that most teams write themselves in under an hour. Adopting a third-party config to avoid writing that file trades a one-time authoring cost for a permanent, unpriced external dependency. The architecture "fit" is therefore not about compatibility — it is about whether an opinionated ruleset from an unrelated organization should govern your codebase's automated rewrites.

Technical risk. High, concentrated in a few areas:

• Abandonment. 0 stars, 0 dependents, and a score of 0 indicate no external consumption and no community pressure to maintain. Any breakage is yours.
• Supply-chain surface. Rector sets are executable PHP evaluated at tool runtime. Pulling an unaudited config package into a build pipeline means executing third-party code with your source tree in scope. Low blast radius (it mutates files, it doesn't ship to prod), but non-zero and easy to overlook.
• Version coupling. Rector's API and set semantics move between major versions (config class names, withSets signatures, deprecated rules). A config package pinned to an older Rector major will either block your Rector upgrades or silently diverge in behavior.
• Implicit assumptions. Internal configs routinely hardcode paths (src, tests), PHP version targets, and framework-specific rule groups (Symfony/Laravel/Doctrine). These fail quietly — Rector skips rules rather than erroring — which is the worst failure mode: you believe refactoring happened when it didn't.
• Naming and discoverability. Zero stars means zero external bug reports. Undocumented behavior is the default, not the exception.

Key questions to resolve before any decision.

1. Does the package publish sets (composable) or a full rector.php (opinionated, not composable)?
2. Which Rector major versions are supported, and is the constraint expressed in composer.json or only implied?
3. What does it assume about project layout, PHP version, and framework?
4. Is there a license file? Any tags/releases, or only dev-main?
5. Is the upstream repo actively committed to, or is this a one-shot publish?
6. Can the actual rules be enumerated by reading the set files in under an hour? (If yes, the dependency is avoidable.)

Integration Approach

Stack fit. Acceptable only for PHP projects already standardized on Rector. It is a non-fit for polyglot repos, for projects using Pint/PHP-CS-Fixer only, or for teams without an existing Rector baseline — introducing Rector and a borrowed ruleset simultaneously conflates two changes.

Recommended path: extract, don't depend. The highest-value integration is to read the upstream set files, copy the rule list into your own rector.php, and attribute the source. This preserves the useful part (curated rule selection, ordering, skip lists) while eliminating the dependency, the version coupling, and the supply-chain question. Concretely:

1. Clone and read the repository; enumerate every rule and skip-list entry.
2. Diff against your current config or a Rector-generated baseline (vendor/bin/rector init).
3. Adopt selectively — take rules that match your standard, drop framework rules you don't use.
4. Commit as first-party config with a comment crediting the source and the commit SHA reviewed.

If you must depend on it (e.g., you want to track upstream changes deliberately):

• Pin to an exact tag or commit, never dev-main; Rector configs have no BC promise.
• Constrain Rector itself in composer.json to a matching major.
• Vendor it as a require-dev dependency only — never in production installs.
• Run it in a dedicated CI job on a branch with a diff review gate before any automated commit.

Compatibility. Verify PHP version floor and Rector major before anything else; those two constraints are where this class of package breaks. Check whether the set files use APIs deprecated in your Rector version — the failure is usually a fatal in the config file itself, which is at least loud.

Sequencing. (1) Audit contents → (2) decide extract vs. depend → (3) if extracting, land first-party config behind a dry-run CI job → (4) observe one or two real refactor runs → (5) only then enable automated commits. Do not make this the first Rector config a team encounters; establish a working baseline first so you can attribute behavior changes to the ruleset rather than to Rector itself.

Operational Impact

Maintenance. Effectively zero upstream maintenance guarantee. The realistic assumption is that you own the ruleset from day one, whether or not you composer require it. Budget the extraction effort (~half a day for a mid-size repo) as the true adoption cost; the dependency route defers but does not avoid it.

Support. None. No issues culture (0 stars implies no issue traffic), no changelog discipline to rely on, no maintainer SLA. Internal escalation path is "read the PHP and figure it out," which is fine for a config file and unacceptable for anything load-bearing.

Scaling. Not applicable in the conventional sense — this is per-repository developer tooling, not a runtime component, so it does not participate in traffic, latency, or capacity planning. The scaling concern is organizational: N repositories each pinning different commits of an unmaintained config produces N divergent code styles with no forcing function to converge. Centralizing the extracted rules in an internal standards package is the scalable form of this, and it is roughly the same work.

Failure modes, ranked by likelihood:

1. Silent rule divergence — config targets an older Rector, rules are skipped, team believes refactoring is applied. Highest risk because it is invisible.
2. Hard break on Rector upgrade — config file fatals on a changed class or method name. Loud, cheap to fix, but blocks the Rector upgrade until patched.
3. Path/framework assumptions — rules meant for src/ miss your layout, or framework-specific rules mangle code they were never meant to touch. Mid-severity: caught in diff review if you have one.
4. Unexpected destructive rewrite — an aggressive rule fires on code the original authors never had. Low likelihood if you dry-run first; high cost if it lands in an automated commit.
5. Supply-chain compromise — an unaudited config package executing at build time. Low likelihood, but the reason to prefer extraction.

Ramp-up. Near zero for any PHP developer — reading a Rector set file requires no specialized knowledge, and the tool's own docs cover the API. The real ramp-up cost is organizational, not technical: convincing a team to adopt an unmaintained external opinion, or to accept the extraction work instead. Given 0 stars, 0 dependents, and no community validation, the defensible recommendation is to treat this repository as reference material, not a dependency — mine it for rule selection, credit it, and move on.