Product Decisions This Supports
- Build vs. buy vs. skip: This is a free, MIT-licensed, dev-only dependency — the "build" alternative is writing custom static checks or relying on tribal code review. Adopt rather than build; there is no runtime footprint or licensing cost to weigh.
- Refactoring and upgrade roadmap: It is effectively a "pre-flight check" for Laravel upgrades and large refactors. Running its checks (
check:all, route/view/import checks) before and after a framework bump or module extraction gives a cheap signal on broken references, wrong namespaces, missing imports, dead controllers, and orphaned Blade views — the class of errors unit tests usually miss because nothing executes that path.
- CI gate / definition of done: Decide whether these checks run as advisory (report-only) or blocking in the PR pipeline. Start advisory, promote the noisiest-free subset to blocking once false positives are baselined.
- Tech-debt triage: Its output doubles as a prioritized cleanup backlog (unused routes, unused views, import mistakes) that can be sized and scheduled rather than discovered during incidents.
- Onboarding and codebase literacy: New engineers get a machine-generated map of "things that look wrong here," which shortens ramp-up on legacy Laravel apps more than documentation usually does.
- Scope boundary you must set explicitly: This does not replace PHPUnit/Pest, and it does not replace PHPStan/Larastan. It answers "does this code follow Laravel's structural expectations," not "is the logic correct." Frame it as a third, cheap layer — not a testing strategy.
When to Consider This Package
Adopt when most of these are true:
- You own a Laravel application (not a library/SDK) with meaningful Blade, routing, and controller surface area.
- You're planning a Laravel major-version upgrade or a large refactor (splitting a monolith, extracting modules) and want a low-effort safety net beyond the test suite.
- You already have CI and a culture of PR gates; the value is realized only when the checks run automatically.
- Your team is mid-sized or larger, or has high contributor churn, so review attention is scarce and structural mistakes slip through.
- Your existing static analysis is thin or absent — if you have nothing today, this is the cheapest first step.
Look elsewhere or defer when:
- You already run Larastan/PHPStan at a high level plus Pint and Rector. Overlap grows and you'll end up maintaining two suppression lists. Verify the specific checks add signal before adding a tool.
- Non-Laravel or framework-agnostic codebases, or Laravel packages/libraries where your consumers' structure differs from app conventions.
- You cannot tolerate false positives in CI. Heavily dynamic code (runtime-registered routes, magic view resolution, custom container conventions) will produce noise you must baseline — budget for that or the gate gets disabled in week two.
- Governance-sensitive teams. It is essentially a single-maintainer project (1.5k stars, near-zero downstream dependents recorded on Packagist). That is fine for a dev-only tool with an MIT license — you can fork — but it argues for version pinning, no production dependency, and a willingness to drop it.
- You need IDE-level, in-editor feedback. This is CLI/CI-shaped, not a language server.
How to Pitch It (Stakeholders)
For executives (30 seconds): A free, dev-only tool that scans our Laravel codebase for a specific class of structural bugs — broken imports, wrong namespaces, routes pointing at code that no longer exists, blade templates referencing missing views. These bugs are invisible to unit tests and expensive to find in QA or production. It adds roughly an hour of setup to our CI and reduces rework during our upcoming Laravel upgrade. No runtime dependency, no license cost, no vendor lock-in (MIT, and it never ships to production).
For engineering leadership: It's a static analysis layer, not a test framework. Cost is one dev-day to install, baseline, and wire into CI; ongoing cost is triaging findings and curating an ignore list. Benefit is a cheaper upgrade and refactor cycle and a standing backlog of structural debt. Risk is low and reversible — it's require-dev, pinned, and removable in one commit. Main caveat: small maintainer base, so treat it as a convenience tool rather than load-bearing infrastructure, and expect some false positives that need baselining before the check becomes blocking.
For the engineering team: Add it, run it, look at the output before deciding anything. Promote findings to blocking CI only for the categories that are clean on day one. Keep it clearly separated in docs from PHPUnit and PHPStan so nobody mistakes it for either.