Phpstan Rules Wrapper Laravel Package

Technical Evaluation

Architecture fit. This is a Composer metapackage, not a framework component. It ships no application code: its entire payload is a composer.json that requires eleven third-party PHPStan rule packages plus a phpstan.neon that enables them, and it relies on phpstan/extension-installer to auto-register everything on install. That makes it a configuration consolidation artifact. It fits only projects that already run PHPStan; for a Laravel codebase with no static analysis, adopting this means adopting PHPStan, extension-installer, and an opinionated opinion-set in one step.

Integration feasibility. Mechanically trivial — one composer require and zero application code changes, no runtime surface, no migrations, no service wiring. Rollback is a single composer remove. The real cost is behavioral, not mechanical: because extension-installer auto-loads every bundled ruleset, the first run will emit the union of eleven rule sets' findings against a codebase that has never been measured against them. For a mature Laravel app that is realistically hundreds to low thousands of new errors.

Technical risk.

• Bundle semantics, not a facade. The package is not a curated, tunable wrapper — it is an aggregator. You cannot easily opt into "half of it"; you get all eleven rule sets and then suppress via ignoreErrors, which is the worst kind of configuration debt.
• Version coupling to PHPStan majors. The 10.0.0 release was explicitly a PHPStan v2 realignment, and it dropped ergebnis/phpstan-rules because that package hadn't caught up (re-added in 10.1.0). This pattern means the wrapper's major versions gate your PHPStan upgrade timing, and a lagging upstream rule package can block you.
• Silent coverage drift. Release 10.14.0 disabled two ergebnis rules as a bug fix; 8.0.0 dropped thecodingmachine packages entirely. Coverage can shrink in a "minor" release. Your quality gate is not stable by contract.
• Single-maintainer, Renovate-driven. Nearly all recent releases are dependency bumps by one bot and one person. Version numbering has already jumped 9 → 10 → 14 within the visible window. 6 stars and 0 dependents means essentially no field validation; you would be an early adopter of a convenience layer over well-known packages.
• Supply chain. Dev-only and CI-only, so blast radius is the build environment rather than production — but PHPStan extensions are executable code, and auto-installation means trust is implicit.

Key questions.

1. Do we already run PHPStan, and at what level? If not, this package is not the entry point.
2. Which of the eleven rule sets do we actually want? Can we justify each, or are we accepting defaults we haven't read?
3. What is our PHPStan upgrade cadence, and will this wrapper's major bumps dictate it?
4. Who owns the ignoreErrors baseline, and what is the policy for retiring entries?
5. Is the maintainer's rule philosophy (e.g. wyrihaximus/phpstan-no-safe, strict types, dead-code detection) compatible with our code style, or will it generate noise we permanently suppress?
6. Can we pin exactly and treat upgrades as reviewed PRs rather than auto-merges?

Integration Approach

Stack fit. Appropriate for PHP 8.x Laravel applications and libraries that (a) already have PHPStan in require-dev, (b) have phpstan/extension-installer allowed in composer.json's allow-plugins, and (c) have CI capable of running analysis on every PR. It is a poor fit for teams that have not yet reached PHPStan level 5–6 clean, because the incremental signal from strict/type-coverage rules is drowned by baseline noise at lower levels.

Migration path. Treat this as a greenfield quality-gate decision, not a dependency swap.

1. Baseline first. On a branch, record current PHPStan version, level, error count, and CI duration. Do nothing else.
2. Install in isolation. composer require --dev wyrihaximus/phpstan-rules-wrapper, confirm extension-installer registers it, run analysis, and capture the new error count by rule identifier. That distribution is the decision input.
3. Triage by rule set. Split findings into: fix now (cheap, high value), baseline (accepted debt), and reject (rule actively wrong for us — disable explicitly in phpstan.neon with a comment and an owner).
4. Gate non-blocking first. Land the baseline, wire CI to report but not fail, and run for two to four weeks to measure churn.
5. Flip to blocking, then ratchet the baseline downward with a policy of "no new entries without a ticket link."

Compatibility. Pin the wrapper exactly ("14.5.0" or a tight range) rather than ^, because its minors carry rule changes. Keep PHPStan itself on an explicit version too; the wrapper's major tracks PHPStan's major, so upgrade them in the same PR. Verify PHP version constraints across all eleven transitive rule packages — the tightest one governs.

Sequencing. Do not combine this with a PHPStan level increase, a Laravel major upgrade, or a PHP version bump. Each of those changes the error population independently, and confounding them makes the baseline unattributable. If a bundled rule package is abandoned mid-adoption (the ergebnis/PHPStan v2 episode is the precedent), be prepared to pin the wrapper to the last working minor and wait, or vendor the specific rule set directly and drop the wrapper.

Operational Impact

Maintenance. Ongoing effort is dominated by dependency churn, not by this package's own code. Expect frequent patch/minor releases; a Renovate or Dependabot PR per week is plausible. Budget roughly one review cycle per month for the wrapper and its lockfile delta. The real maintenance cost is the ignoreErrors baseline — an unowned baseline grows monotonically and quietly converts the gate into theater.

Support. Support options are the GitHub issue tracker and the maintainer's discretion. No vendor, no SLA, no LTS. Mitigation is architectural, not contractual: because the package is a thin aggregator, the exit path is to composer remove it and require the individual rule packages you actually use, copying over the relevant phpstan.neon includes. Keep a note of which includes you rely on so that exit takes an hour, not a day.

Scaling. Effectively free at any repository size — analysis cost scales with codebase size and PHPStan settings, not with the number of rule packages. The scaling concern is organizational: across many repos, an auto-loading metapackage means every repo silently inherits whatever the maintainer shipped that week. Standardize on an exact pinned version in a shared internal tooling package and let teams opt into upgrades deliberately.

Failure modes.

• Silent rule removal or disablement in an upstream release — coverage drops with no local change. Detect by snapshotting the active rule list in CI and diffing it.
• Upgrade deadlock — a bundled rule package lags a new PHPStan major, blocking your PHPStan upgrade (precedent: 10.0.0). Mitigation: pin, and hold a documented rollback version.
• Baseline creep — new findings suppressed into ignoreErrors by default. Mitigation: baseline review at each upgrade, and cap its size.
• CI environment failure from an incompatible transitive constraint after a composer update on an unrelated package. Mitigation: lockfile discipline and a dedicated CI job.
• Configuration collision — the wrapper's includes fight with project-level phpstan.neon settings or with another auto-registered extension. Diagnose with phpstan --debug style output of the resolved config.

Ramp-up. Engineer time to first successful run is under an hour; time to a trustworthy, blocking gate is closer to one to two weeks of triage for an established codebase. Knowledge transfer is minimal but concentrated: one person should own the phpstan.neon configuration and the baseline, and that ownership should be explicit, because this package's value proposition — one-line adoption of eleven rule sets — is exactly the kind of convenience that becomes invisible infrastructure no one understands six months later.