Meliorstan Laravel Package

Product Decisions This Supports

• Static-analysis investment decision: whether to formalize a PHPStan/Larastan-based quality gate in CI, and at what strictness level, versus relying on code review and test coverage alone.
• Build vs. buy for engineering standards: adopting a curated external ruleset instead of having a senior engineer write and maintain in-house Laravel-specific rules. Buying here costs ~zero dollars (MIT) but carries maintenance/vendoring cost; building costs a few engineer-days plus indefinite ownership.
• Platform/DevEx roadmap: whether "consistent code-quality configuration across all Laravel services" belongs as a platform-team deliverable, so product teams stop hand-rolling phpstan.neon files.
• Defect-escape reduction: a lever for shifting bug detection left (type errors, undefined properties, incorrect Eloquent relations, dead code) before QA or production, which affects release cadence and on-call load.
• Onboarding and codebase consistency: a machine-enforced convention set reduces reviewer nitpicking and shortens ramp-up on unfamiliar Laravel codebases.
• Upgrade/migration risk planning: a dependency on PHPStan internals means roadmap decisions about when to take PHPStan major versions are coupled to whether this package keeps pace.

When to Consider This Package

Consider it when:

• You already run (or are about to run) PHPStan with Larastan on one or more Laravel codebases and want a faster path to a stricter, framework-aware baseline.
• You have multiple Laravel services/repos and want one shared, versioned ruleset rather than N divergent configs.
• You have CI minutes to spare and a team that will act on new findings — an unused ruleset is pure cost.
• You can pin the version and accept that you may need to fork or drop it at the next PHPStan major.
• You've done a two-week spike: measure new-issue count, false-positive rate, CI time delta, and remediation effort on your worst repo before broad rollout.

Look elsewhere when:

• You have a single small app or no CI pipeline — configure Larastan directly; a thin wrapper adds little.
• You need vendor support, SLAs, or security guarantees — 20 stars and a likely single maintainer is a bus-factor-1 dependency.
• Your organization requires proven adoption / long-term maintenance commitments for build tooling.
• Your Laravel/PHPStan versions are ahead of or behind what the package supports; rule packages break hard on analyzer major upgrades.
• The ruleset's opinions conflict with your team's conventions and would generate noise you'd suppress into irrelevance.

Verification before adoption: confirm which PHPStan/Larastan versions are supported, whether rules are configurable or all-or-nothing, the suppression story, and the maintainer's response history on issues. Treat 20 stars as "evaluate," not "standardize."

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, permissively licensed (MIT) add-on that makes our PHP static analysis stricter and more Laravel-aware. The business case is defect prevention: it catches a class of bugs — wrong types, broken model relations, unreachable code — before they reach QA or customers, and it standardizes code quality across our Laravel services so reviews focus on design rather than syntax. Cost is near zero in licensing and modest in CI time; the real cost is a short evaluation and the possibility we maintain our own copy. Recommendation: a timeboxed pilot on one high-churn repo, with success measured by defects caught pre-merge and CI time added, before any org-wide commitment. We should not treat it as a strategic platform dependency at its current adoption level.

For engineering: It's a drop-in ruleset on top of Larastan/PHPStan — MIT, easy to pin, easy to remove. Expect to tune severity, suppress a handful of rules that fight our conventions, and re-validate on every PHPStan major. Budget a day for the spike plus remediation on the pilot repo, and assume we own a fork if upstream goes quiet.

For finance/procurement: No license fee, no contract, no data leaving our environment — it's a dev-time dependency only. Risk is maintenance, not spend.