Phpstan Config Laravel Package

Technical Evaluation

Architecture fit. Low-coupling but shallowly so. This is not a Laravel package in any runtime sense — no service provider, no facade, no artisan command, no configuration published into config/. It is a PHPStan configuration preset distributed via Composer: a set of .neon files (base ruleset, level, ignore patterns, possibly stubs and a baseline) that a consuming project include:s from its own phpstan.neon. The integration surface is a single include line and a dev-dependency. For a TPM, that means it sits entirely on the quality-gate layer of the SDLC, not on the application critical path. It cannot take down a request, cannot alter runtime behavior, and can be removed with one composer remove. The architectural fit question is therefore not "does this slot into our Laravel app" — it does, trivially — but "does a privately-hosted, zero-adoption preset belong in our toolchain supply chain at all."

Integration feasibility. Mechanically trivial, logistically questionable. The package lives on gitlab.irstea.fr, the internal GitLab of a French agricultural research institute (IRSTEA, now part of INRAE). Composer cannot resolve it from Packagist; adoption requires a repositories entry pointing at the private VCS host plus SSH or token credentials on every CI runner and developer machine that installs dev dependencies. That is the gating constraint. If our runners cannot reach that host — network policy, credential rotation, institutional DNS or repo archival — the package is not installable, and the assessment ends there.

Technical risk. Asymmetric and dominated by supply-chain and staleness concerns rather than code risk. A bad preset manifests as false positives (noisy CI, developer friction, people adding ignoreErrors to silence the tool) or false negatives (missed defects, a weaker gate than we believed). Neither touches production. The material risks are: (a) abandonment — a score of 0, zero stars, zero dependents, and a host organization that has already rebranded once gives us no signal that the preset will track PHPStan major versions; (b) version pinning — if composer.json pins phpstan/phpstan to a narrow range, it will actively fight our own PHPStan upgrade cadence; (c) baseline contamination — if the preset ships an IRSTEA-scoped baseline, we inherit ignores tuned to someone else's codebase and blind ourselves to real findings.

Key questions.

• Is the package mirrored on Packagist or a public registry, or internal-only? If internal, is there a documented, sanctioned access path for third-party CI?
• What is the phpstan/phpstan constraint and PHP version floor — pinned or range? Does it survive the 1.x → 2.x ruleset restructuring?
• Does it ship a baseline, and is that baseline scoped to IRSTEA's code?
• Who owns the repo, and what is the change policy? A shared preset is a shared contract; silent rule changes propagate across every consumer at once.
• Was this intended for external consumption at all, or is it an internal default that surfaced in a dependency scan?

Integration Approach

Stack fit. Poor as a hard dependency, useful as a reference artifact. Our Laravel services want Laravel-aware analysis, which is larastan/larastan's job; a generic house-style preset from an unrelated research institute adds little and overlaps with Larastan's own extension config, creating a double-configuration problem. This package fits only if we are already inside the INRAE/IRSTEA ecosystem — which we are not.

Migration path. Recommend read-and-fork over depend. The entire payload is a handful of human-readable .neon files; reviewing them is an afternoon of work. Clone, read, extract anything genuinely valuable (level choice, common Laravel ignoreErrors, tmpDir/parallel/cache settings), and fold it into either our existing root phpstan.neon or a first-party preset package under our own namespace. This removes the private-registry resolution path, the version pin, and the abandonment exposure in one move. If we must consume it directly, vendor a pinned copy into our monorepo's tooling directory rather than resolving from a private GitLab at build time.

Compatibility. Inspect composer.json for the PHPStan constraint and PHP floor before anything else. NEON parameter names and ruleset structure shift between PHPStan majors; validate any lifted content against the exact PHPStan version we run, on a real service, before it becomes a gate. Flag overlap with Larastan explicitly so we do not enforce two competing rule sets.

Sequencing. (1) Sandbox-resolution test — confirm the package is installable at all from our environment. (2) If resolvable, diff its config against our current phpstan.neon. (3) Lift useful rules into a first-party preset with a license and provenance note. (4) Run against a representative service at our current level and compare findings, to establish whether the preset changes signal or just noise. (5) Introduce into CI as a non-blocking check first, then ratchet to required. Do not block any delivery on this — it is tooling hygiene, not a feature dependency.

Operational Impact

Maintenance. Zero if forked and owned internally; unbounded if depended upon externally. There is no maintainer signal — no stars, no dependents, no visible release cadence — so assume no upstream support. Forking converts an unknown external maintenance burden into a small, well-understood internal artifact with a named owner.

Support. No community, no issue tracker we can reasonably rely on (internal GitLab), no SLA. Any breakage becomes our incident to debug against PHPStan internals. Treat it as unsupported software and staff accordingly.

Scaling. Negligible technical cost — the preset runs only during static analysis in CI and adds no runtime overhead. The scaling concern is organizational: every repo that depends on it inherits the private-registry path and the version pin, so the coupling multiplies across the fleet and the blast radius of a host outage multiplies with it. A single first-party preset collapses that to one source of truth.

Failure modes.

• Resolution failure — CI cannot reach gitlab.irstea.fr (network policy, credential rotation, institutional DNS change); builds break for reasons unrelated to our code.
• Version drift — a PHPStan major invalidates preset syntax; CI fails or, worse, silently drops rules.
• Silent rule relaxation — an upstream edit lowers effective strictness and we discover it only when a defect escapes that a stricter rule would have caught.
• Baseline contamination — an IRSTEA-scoped baseline blinds us to real issues or floods us with irrelevant ones.
• Ghost dependency — an ownerless, consumer-less preset can be archived or deleted without notice.

Ramp-up. Minimal for engineers; reading a NEON file is trivial. The real cost is governance — standing up an internal tooling-config repo, a review process for rule changes, and a CI contract for how presets are consumed. That investment is worth making regardless of this package and neutralizes the dependency question entirely.

Recommendation. Do not take a production dependency on irstea/phpstan-config. Review its contents, lift anything useful into a first-party PHPStan preset we own, and move on. A score of 0 with zero dependents is the correct read: this is internal plumbing that surfaced in a dependency scan, not a distributable package.