Php Static Analysis Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for quality infrastructure. Static analysis is table-stakes engineering hygiene, but every PHP team hand-rolls its own PHPStan/Psalm/PHP-CS-Fixer/Rector config, then drifts. This package is a "borrow" option: adopt a curated ruleset instead of spending a sprint writing one. The PM decision is whether config-as-a-dependency beats config-as-a-repo-template.
• Standardization across squads and repos. Multi-team PHP estates diverge on analysis strictness. Bundling the ruleset means every service fails the build on the same class of defect, which makes defect-escape and code-review metrics comparable across teams — a prerequisite for any honest engineering-quality dashboard.
• Gating policy and roadmap sequencing. A shared ruleset lets you ratchet strictness deliberately (baseline violations, then fix-forward per quarter) rather than arguing level-by-level in each repo. That converts "improve code quality" into a roadmap line item with a measurable exit criterion.
• Tech-debt and risk visibility for non-engineers. The output of static analysis is the closest thing most PHP orgs have to a quantified risk register in code: type errors, dead code, unsafe patterns. This package lowers the cost of turning that signal on, which feeds security review, audit readiness, and release-confidence conversations.
• Onboarding and platform-consistency decisions. If new repos start from a scaffold that includes this package, time-to-first-green-build drops and you avoid the classic "legacy repo can never be brought in line" trap that blocks consolidation onto a shared platform.
• Use cases where it is genuinely useful: internal services with a stable PHP/Laravel version matrix; teams with no dedicated platform engineer; consultancies shipping many small Laravel apps; pre-acquisition or pre-audit hardening sprints.

When to Consider This Package

Consider adoption when: you run multiple PHP/Laravel repos and want one opinionated baseline; you have no platform team to own a bespoke config; you want a fast, low-effort first CI gate; your PHP and framework versions sit inside the package's supported matrix; and you are willing to fork it if maintenance stalls.

Look elsewhere — or plan to fork immediately — when any of these hold:

• Continuity risk is unacceptable. Zero stars and zero dependents means you are effectively the first production adopter. There is no community to absorb a breaking change, no issue history to mine, and no guarantee of PHP-version support on your timeline. Price in owner-maintenance cost as an explicit line item.
• You need strictness control per repo. Opinionated configs are only valuable if you can override them. Verify the escape hatches (ignore lists, per-path levels, per-rule opt-out) before committing; a bundled config you cannot relax becomes a reason teams disable analysis entirely.
• Regulatory or supply-chain review applies. For regulated codebases, a single-maintainer, unreferenced dependency fails most third-party risk questionnaires. Vendor it into your own monorepo with a pinned commit rather than depending on it live.
• You need runtime or Laravel-aware analysis beyond what the bundled tools cover — in which case Larastan plus your own config is the more defensible bet.
• Your stack is heterogeneous. If PHP is a minority of your estate, a single-language config package doesn't justify the added dependency; prefer a polyglot CI template.

Evaluation checklist before saying yes: read the actual bundled ruleset line by line (it is the product); confirm supported PHP/Laravel versions against your matrix; run it in one non-critical repo and measure violations-per-KLOC and false-positive rate; confirm CI runtime impact; confirm licence compatibility; and write down the fork-and-own plan.

How to Pitch It (Stakeholders)

For executives: Static analysis catches a class of defects before they reach customers, at near-zero marginal cost. This package is a pre-written quality policy for our PHP services — turning "we should improve code quality" into a concrete, enforceable gate without a dedicated platform hire. Framed honestly: it is a small, low-adoption open-source config, so we treat it as a starting template we may fork and own, not as a supplier we depend on. Upside is a faster first CI gate and comparable quality metrics across teams; downside is bounded at "we wrote our own config anyway," which was the status quo.

For engineering: One shared ruleset instead of N bespoke ones. Lower setup cost per repo, consistent failure modes, and a credible path to ratcheting strictness over time. Known trade-off: we own the config if upstream goes quiet, and we need per-repo overrides from day one. Recommendation: pilot in one repo behind a non-blocking CI stage, review the violation report with the team, then promote to blocking once the baseline is clean — and only then decide whether to keep the dependency or vendor the config in-house.