Product Decisions This Supports
- Build vs. buy for static analysis configuration. Instead of your team spending sprint capacity hand-picking, versioning, and reconciling a dozen PHPStan rule packages, this wrapper bundles eleven curated rulesets (strict rules, deprecation rules, PHPUnit/Mockery integration, dead-code detection, PSR-3 logging rules, type coverage, and more) into one dependency. The decision it simplifies is: "do we invest engineering time curating an internal PHPStan preset, or do we adopt an opinionated external baseline?"
- Quality-gate standardization across repos. If multiple Laravel/PHP services exist, this package gives you a single, consistent definition of "strict enough." That's a governance decision — how much static-analysis rigor is the default for every team — rather than a per-project debate.
- Technical-debt roadmap prioritization. Rules like dead-code detection and type coverage produce measurable signals (percentage of typed code, unreachable/unused code) that can be tracked release-over-release. That turns "improve code quality" from a vague initiative into a metric with a trend line you can put in a roadmap review.
- CI/CD investment decisions. Because it works out of the box via
phpstan/extension-installer, the adoption cost is near zero, which makes it easy to justify trialing in CI before committing to a paid SAAS static-analysis tool.
- Upgrade/maintenance risk register. The release history is dominated by dependency bumps and periodic major-version churn (PHPStan v2 migrations, dropping/re-adding
ergebnis/phpstan-rules, disabling specific rules that caused friction). That's evidence for a standing decision about how much you're willing to inherit someone else's upgrade cadence.
- Onboarding and developer-experience decisions. A shared ruleset shortens code-review debate ("should this be typed?") by pointing at a tool instead of an opinion — relevant when deciding how much review time to spend on style vs. product work.
When to Consider This Package
Consider it when:
- You're on PHPStan already (or planning to be) and want a fast, opinionated, batteries-included ruleset without assembling ten packages individually.
- You have a Laravel/PHP monorepo or multiple services and want one consistent baseline rather than N bespoke
phpstan.neon files.
- Your team has limited appetite for tooling maintenance and prefers to outsource rule curation to a maintained bundle.
- You're running PHPUnit and/or Mockery — the bundle includes the corresponding PHPStan extensions, which otherwise require separate setup.
- You're early in a quality initiative and want measurable levers (type coverage, dead code) quickly.
Look elsewhere when:
- Supply-chain risk tolerance is low. Six stars, zero dependents, and a single maintainer (Cees-Jan Kiewiet) mean this is a personal meta-package, not an ecosystem standard. If your org requires proven adoption or a support contract, this fails.
- You need fine-grained control. The wrapper's value is its opinionation; if you want to cherry-pick two rules and tune thresholds, install the underlying packages directly. Several rules are already disabled upstream (e.g.,
noNamedArgument, noNullableReturnTypeDeclaration), so "strict" here is someone else's definition of strict.
- You're not on PHPStan, or you're on a different analyzer (Psalm, PHP_CodeSniffer-only shops). This is a PHPStan-only tool.
- Version-pinning discipline matters. The wrapper tracks PHPStan and upstream rule packages closely, and has shipped breaking majors when upstream did. Pin it and budget for periodic upgrade work.
- You need vendor/legal review of every transitive dependency. Eleven bundled rulesets means a large transitive dependency graph to evaluate for license and security posture.
How to Pitch It (Stakeholders)
For executives: This is a low-cost, low-commitment way to raise code quality across our PHP/Laravel services. It's a single open-source dependency (MIT license, no purchase cost) that turns on a curated set of automated code checks — catching dead code, missing type declarations, deprecated API usage, and test-related mistakes before they reach production. The upside is fewer defects and less review time spent on style; the risk is that it's maintained by a single volunteer, so treat it as an accelerator, not a foundation. Recommendation: pilot in one repo, measure defect and review-time impact over a quarter, then decide whether to standardize or replace with an internal preset.
For engineering leadership: It's a thin wrapper that installs and auto-registers eleven PHPStan rulesets, so adoption is one composer require and zero configuration. That means we can evaluate it for free in CI this sprint. The trade-off is upstream coupling: the package follows PHPStan's release cadence and has historically shipped breaking majors when PHPStan or a rule package moved. We'd pin the version, own the upgrade, and expect to spend a small amount of maintenance each time PHPStan majors.
For engineers: You get strict rules, deprecation detection, PHPUnit/Mockery awareness, dead-code detection, and type coverage without wiring up each package. Read the config before assuming the defaults match our standards — some rules are disabled for good reasons — and be ready to suppress or tune rules that don't fit our codebase rather than fighting them.
Bottom line: Adopt as a pilot / accelerator, not as infrastructure you depend on. Its value is speed of setup and a defensible, opinionated baseline; its cost is inherited maintenance and single-maintainer risk.