Phpstan Config Laravel Package

Product Decisions This Supports

• Code-quality baseline standardization — Treats the PHPStan configuration as a shared, versioned artifact rather than per-repo folklore. This supports the decision to enforce one static-analysis policy (level, ruleset, ignores, analyzed paths) across every PHP service we own.
• Build vs. buy vs. adopt — Informs whether we fork a config, publish our own internal phpstan.neon preset package, or pull an existing one. Adopting a shared config package is a small, low-risk "adopt" decision compared to taking on a framework or runtime library.
• CI/CD gating policy — Whatever the preset prescribes (error level, baseline handling, excluded paths) becomes the gate in CI. Adoption is effectively a decision about what breaks the build, i.e. a product-visible quality bar.
• Roadmap sequencing for quality uplift — A central config lets us ratchet the PHPStan level in one place and propagate it org-wide, instead of renegotiating per repo. This supports a phased "tighten the net" roadmap rather than a big-bang cleanup.
• Onboarding and developer experience — New PHP repos get a working analysis setup in one Composer line plus an includes: entry, reducing setup time and the "why does my repo fail on main?" class of support tickets.
• Supply-chain and provenance posture — Deciding to depend on a third-party tooling package (versus owning the config) is itself a product/engineering risk decision, given the maintenance and hosting concerns below.

Caveat for the decision record: this package shows zero stars, zero dependents, and lives on a self-hosted GitLab (gitlab.irstea.fr). Treat it as an internal artifact of its originating organization, not a community-vetted dependency. The realistic product decision is "review and vendor/fork the config into our own repo," not "add a runtime dependency on this package."

When to Consider This Package

Consider it when:

• You are inside the originating organization (IRSTEA/INRAE) or a closely aligned team already using PHPStan across multiple PHP projects.
• You want one source of truth for PHPStan settings and are tired of copy-pasted phpstan.neon files drifting apart.
• You value convention over configuration and are happy to accept the package's chosen level and ruleset largely as-is.
• You want a small, readable set of sensible ignoreErrors / tmpDir / parallel settings to lift into your own config.
• You can pin a version and accept that upstream upgrades may be infrequent and undocumented.

Look elsewhere when:

• You need Laravel-specific analysis — use larastan/larastan, which bundles Laravel-aware rules, stubs, and a maintained config. (The description claims "Laravel-friendly defaults," but this is a generic preset; don't rely on it for framework-aware analysis.)
• You need a maintained, versioned, community-supported base config with changelogs, semver guarantees, and issue tracking you can rely on.
• You require custom rules, baseline management, or per-directory overrides — a thin default config won't carry that; write your own.
• You cannot reach the package's GitLab host, or you have policies against depending on other organizations' internal repos at build time.
• You need to support multiple PHP versions or exotic frameworks in one org and want composable rule sets rather than a fixed default.
• Your team is small enough that a single checked-in phpstan.neon is simpler than an extra dependency.

Recommended posture: read the shipped .neon files (a config file is cheap to audit), and if the ruleset fits, copy the useful parts into a first-party repo with a license and provenance note. You get the standardization benefit without the private-registry dependency or abandonment risk.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are standardizing how we check PHP code quality before it ships. PHPStan is the industry-standard static analyzer for PHP; this package is a shared, pre-tuned configuration for it. Adopting a single shared config — whether this one or our own fork — means every PHP service is held to the same quality bar, defects are caught in CI instead of production, and engineers stop re-arguing the rules per repository. The cost is near zero (a config file plus a CI step); the benefit is fewer escaped defects and faster onboarding. Because this particular package has no public adoption, no maintainer signal, and is hosted on an external organization's private GitLab, I recommend we fork the config into our own repository rather than take a direct dependency — we keep the standardization benefit while owning maintenance and supply-chain risk.

For engineering (the ask):

• Read the shipped .neon file(s), confirm the PHPStan level and ruleset match our intent, and note any ignores, baselines, or excluded paths we disagree with.
• Vendor it into our-org/phpstan-config (or a shared template), pin the PHPStan version, and document the upgrade path.
• Wire it into CI as a required check; introduce it at the current effective level first, then ratchet up.
• Validate NEON syntax and parameter names against the PHPStan major version we actually run — preset configs are sensitive to the 1.x → 2.x ruleset restructuring.
• Flag overlap with larastan for Laravel services so we don't double-configure or get conflicting rules.

Bottom line: the idea — a shared, versioned PHPStan config — is worth adopting; the package as-is is not a safe dependency. Review it, fork it, own it, and use it as the mechanism for a deliberate, incremental code-quality bar.