Phpstan Bodyscan Laravel Package

Product Decisions This Supports

• Prioritizing static-analysis debt: gives a ranked, quantified view of which PHPStan error identifiers are being suppressed most often via inline @phpstan-ignore annotations, turning "our code has a lot of ignores" into a defensible backlog ordering.
• Policy on inline suppressions: informs whether to allow bare ignores, require identifiers, or require justifications — you can measure the blast radius of each policy before enforcing it.
• Roadmap for PHPStan level upgrades: establishes a before/after baseline so level bumps and new rule adoption can be justified with numbers rather than anecdotes ("ignore count dropped 40% after the level 8 sprint").
• CI quality gates and trend reporting: the new --json output makes the scan consumable by CI jobs, dashboards, and trend tracking — enabling a suppression-count metric alongside coverage and lint metrics.
• Build vs buy: a single-purpose, dev-only OSS CLI backed by a well-known author in the PHPStan ecosystem is almost always cheaper than writing and maintaining a custom parser/grep harness for the same question.
• Sizing a cleanup initiative: the raised memory limit makes full-project analysis viable on large/monorepo codebases, so scoping estimates are based on complete data rather than a sampled subset.

When to Consider This Package

Consider it when:

• The team already runs PHPStan (especially with a baseline or a meaningful volume of @phpstan-ignore annotations) and cannot easily answer "which rules do we suppress most?"
• The codebase is large enough that manual auditing of suppression comments isn't practical, and you want to run the scan in CI rather than on a laptop.
• You need machine-readable output to feed an internal dashboard or a build gate (satisfied from 0.2.0 onward via --json).
• You want a low-commitment, dev-only dependency with no production runtime footprint and no code changes required to try it.

Adoption criteria: confirm PHP/PHPStan version compatibility with your pinned toolchain, verify the tool's own analysis remains within your CI runner memory budget on your largest repository, and check that the JSON schema is stable enough to build dashboards on (pin the version until it is).

Look elsewhere when:

• PHPStan isn't part of your stack, or the codebase is small enough that a grep over ignore comments answers the question.
• You need per-file blame/ownership attribution, historical time-series, or a hosted UI out of the box — this produces a point-in-time report, not a metrics platform.
• You require vendor support, an SLA, or formal security review for developer tooling; this is a single-maintainer OSS utility.
• Your organization restricts adding dev dependencies, or you need results that don't depend on the analyzed project's PHPStan configuration staying in sync.

How to Pitch It (Stakeholders)

For executives: This is a zero-cost, development-only tool that converts an invisible quality problem — how often we silence static analysis warnings — into a single trackable number. It carries no production risk: it runs in CI or locally, touches no application code, and requires no procurement. The payoff is prioritization: we stop guessing which code-quality work matters and can show measurable improvement over time.

For engineering: One command scans the codebase, reads the PHPStan ignore annotations already in place, and reports counts by identifier. Release 0.2.0 adds --json output, so results can be piped into CI checks or an internal dashboard, and raises the memory limit so full analysis works on large projects. There are no code changes required to adopt it — it's a dev dependency used to build the case for raising PHPStan levels and to keep inline suppressions honest. Recommend pinning the version and trialing it on the largest repository first.