Larastan Config Laravel Package

Product Decisions This Supports

• Quality-gate policy for Laravel services. A shared Larastan preset is a policy artifact, not a library: it encodes "what analysis level do we hold the codebase to, and which errors are allowed to be ignored." Adopting or rejecting it is effectively a decision about the strictness bar your CI enforces on every PR.
• Build vs. buy (vs. copy) for internal tooling. The realistic options are: (a) depend on this package, (b) write an equivalent phpstan.neon in ~20–40 lines, or (c) fork it under MIT. This is a cheap, reversible decision — worth deciding once, deliberately, rather than letting each repo drift into its own config.
• Tech-debt roadmap sequencing. A preset with an ignoreErrors baseline tells you what the authors decided not to fix. If you adopt it, that suppression list becomes your roadmap: each ignored pattern is a candidate for a "burn-down" epic. Conversely, if the ignore list is large and undocumented, that's a signal the preset is compensating rather than enforcing.
• Standardizing onboarding and review load. If multiple teams run Laravel, one reviewed analysis config reduces "why does repo A fail and repo B pass" churn and shortens the loop for new engineers setting up a service.
• Prioritizing CI/tooling investment. Static analysis is a pay-per-PR cost (runtime in CI) against a benefit in escaped defects and review time. A preset is the cheapest way to test whether the organization will tolerate the noise; you can measure false-positive rate and PR friction before committing to a bespoke ruleset.
• Not supported: this is not a runtime dependency, not a feature enabler, and not a differentiator. It should never appear on a roadmap as a deliverable in its own right.

When to Consider This Package

Consider it when:

• You run more than one Laravel codebase and currently have inconsistent or absent PHPStan/Larastan configuration.
• You want a fast, low-effort baseline and are willing to accept someone else's opinionated rule and suppression choices as a starting point.
• You have a policy of "pin and evaluate," can vendor or fork the config, and have an owner who will review the ignoreErrors list line by line.
• You treat it as a reference implementation to read and crib from, which is the lowest-risk use and honestly the most likely correct one.

Look elsewhere when:

• You need validation before depending on it. Zero stars, zero dependents, single-vendor origin — there is no community signal that this config survives contact with codebases other than the author's. That is not disqualifying for a config file, but it means you are the QA.
• You need customization. The moment you override most of the rules, you have paid the integration cost and received none of the shared-baseline benefit; go direct to larastan/larastan and maintain your own phpstan.neon.
• You need support, SLAs, or a security review. MIT and no dependents implies no maintenance commitment. A stale preset pinned against a newer Laravel/PHPStan major is an upgrade blocker, not an asset.
• You are on a single service. The value of a shared preset is amortized across repos; for one repo, write the config inline.
• You need provenance guarantees. Audit whether the pinned version's rules and ignores are documented; an opaque suppression list is a liability you inherit silently.

Caveats to flag in the evaluation: verify the release cadence actually tracks PHPStan/Larastan majors (the advertised last release date looks anomalous and should be confirmed on the repo), and check the ignoreErrors volume and whether it's scoped with paths/counts or written as blanket ignores — blanket ignores quietly convert a strict gate into a decoration.

How to Pitch It (Stakeholders)

For executives: This is a small, reversible tooling decision, not a platform bet. It standardizes the automated code-quality check we run on Laravel pull requests, so every team is held to the same bar without each one inventing its own. Cost is near zero — it's a config-only dependency under a permissive license, no runtime footprint, no lock-in — and the downside is bounded because we can fork or replace it in an afternoon. The honest framing: it buys consistency and a starting baseline, not a quality outcome on its own. If we want a defect-escape or review-time number moved, the config is the precondition, and the work is the burn-down of suppressed issues. Recommendation: pilot on one or two services, measure PR friction and findings, then decide whether to standardize or write our own.

For engineering: Treat this as a reviewed starting point, not an authority. It's one vendor's opinion about Larastan levels and ignored errors, with no adoption evidence behind it — so we pin the version, read the ignore list, and take ownership of anything we accept. If more than a handful of overrides are needed, we drop it and maintain our own phpstan.neon against larastan/larastan directly; that path is short and removes a third-party dependency from our upgrade chain. Success criteria for the pilot: CI runtime delta, ratio of true to false positives in the first two weeks, and whether any suppressed pattern hides a class of bug we care about.