Php Static Analysis Laravel Package

Technical Evaluation

Architecture fit

• The package is a require-dev-only artifact: it configures tooling (almost certainly PHPStan/Psalm/PHP-CS-Fixer-style presets) rather than shipping runtime code. Architectural coupling to the Laravel application is effectively zero, which is the one unambiguous positive.
• The real dependency being introduced is opinion, not capability. Everything this package does is expressible as a phpstan.neon.dist, a .php-cs-fixer.dist.php, and a few CI steps committed directly into the repo. That reframes the buy-vs-build question: we are evaluating whether to outsource lint policy to a third party, not whether to adopt a technology.
• Fit with a standard Laravel stack is contingent on it not conflicting with Larastan, which is the de facto Laravel-aware PHPStan extension. An opinionated preset that hardcodes level, paths, or stub sets can silently override or fight Larastan's bootstrap. This must be verified before any pilot.

Integration feasibility

• Trivially installable, but "installable" is not the same as "adoptable." With 0 stars, 0 dependents, and a score of 0, there is no observable evidence of the package functioning correctly on any codebase other than its author's.
• The dominant technical risk is version-pin collision: a config package that constrains phpstan/phpstan or php-cs-fixer to a specific major will block our own tooling upgrades, including security patches. PHPStan's 1.x → 2.x config surface changed materially, and presets authored against the older shape will not transfer cleanly.
• Second-order risk: silent config drift. If the preset is loaded via includes:, upstream changes to rules land in our CI without a corresponding change in our repo — the opposite of the auditability we want from a quality gate.

Key questions (gate these before any pilot)

1. What exactly does it ship — config files only, or wrapper binaries/scripts? Is the diff against a hand-rolled phpstan.neon.dist non-trivial?
2. Which tools and which exact version constraints does it pin? Does it conflict with Larastan or with our current PHPStan level?
3. Does it support overriding paths, level, and ignore-errors, or is the preset monolithic?
4. What is the license, and is the publishing org (ETSGlobal) committing to maintenance or is this a public mirror of an internal file?
5. Last commit date and supported PHP/Laravel matrix — the missing stars make commit recency the only proxy for health.

Integration Approach

Stack fit

• Treat as a dev-tooling-only dependency. It should never appear in require, never affect autoloading, and never be present in production images. If the package's own composer.json does not cleanly separate dev concerns, that is disqualifying.
• Baseline assumption: our target stack is Laravel + PHPStan (via Larastan) + Pint/PHP-CS-Fixer. The package is only additive if it composes with Larastan; if it substitutes for it, fit is poor because Laravel's dynamic surfaces (facades, Eloquent magic, container bindings) generate volume of false positives without Laravel-aware stubs.

Recommended migration path — vendor the opinions, not the package

• Given zero adoption signals, the correct move is to copy the config files into our repo as a one-time starting template, attribute the source, and own them thereafter. This captures 100% of the package's actual value (the preset rules) and 0% of its risk (abandonment, pin conflicts, silent upstream drift).
• Only take a live composer require --dev dependency if the package ships logic we cannot replicate — e.g., custom rules, a ruleset generator, or maintained stub libraries. Config-only means copy.
• If a live dependency is justified, pin it exactly (no caret), and add a scheduled job that surfaces upstream config diffs as a PR rather than auto-updating.

Compatibility

• Validate against our PHP version matrix and Laravel major before anything else. Config packages frequently lag PHP minor releases because the underlying analysers do.
• Expect PHPStan major-version churn to break the preset. Budget for the package being the blocker on an analyser upgrade we want for its own sake — that trade is usually not worth it.

Sequencing

1. Spike (1–2 days): install on a single representative service, diff the resulting rule set against our current config, record every conflict with Larastan. Decision point: adopt as dependency vs. copy as template.
2. Baseline generation: run the chosen ruleset to produce a phpstan-baseline.neon. On any non-trivial Laravel codebase this will contain hundreds of entries; that is expected and is not a reason to lower the level.
3. Non-blocking CI first: run analysis and publish results as a check or comment, not a required status. Two to four weeks of signal-gathering.
4. Ratchet: make CI blocking, then enforce "baseline may only shrink" — new code must be clean, legacy debt is frozen. This is the only sequencing that survives contact with a real backlog.
5. Decommission the preset dependency (if adopted) once the rules are stable and internalized.

Operational Impact

Maintenance

• With 0 dependents and 0 stars, assume no external maintenance. We become the sole maintainers of our usage, including any breakage on PHP or analyser upgrades. This is acceptable for a copied config template; it is a standing liability for a live dependency.
• Budget roughly 2–4 hours per quarter for config upkeep once stabilized, plus one bounded spike per analyser major version.

Support

• No upstream support channel of any consequence. Escalation path is "we fix it ourselves" — which again argues for copying files into the repo where we already have review and ownership.
• Assign a named internal owner for the ruleset. Unowned lint policy rots into a permanently ignored CI check within two quarters.

Scaling

• Analysis cost scales super-linearly with codebase size. Mitigate with PHPStan's result cache (tmpDir persisted in CI), --memory-limit tuning, and parallel workers. On large Laravel monorepos, expect multi-minute runs and consider path-scoped analysis on PRs with full runs nightly.
• Enforcing a shrinking baseline scales linearly with team size and is the highest-leverage control; a fixed config on a growing codebase does not.

Failure modes (ranked by likelihood × impact)

1. Pin conflict blocks a security upgrade of the underlying analyser — high impact, moderate likelihood. Mitigation: copy the config, don't depend on the package.
2. Silent upstream ruleset change alters CI outcomes with no repo diff — moderate impact, high likelihood if included by reference. Mitigation: composer.lock pinning plus diff-on-update.
3. Larastan conflict / false-positive flood causes the team to disable the gate entirely — high impact, high likelihood if rolled out blocking on day one. Mitigation: non-blocking phase and baseline first.
4. Baseline rot — entries accumulate, never pruned, gate becomes ceremonial — moderate impact, near-certain without a shrink-only rule.
5. Abandonment — moot if we copy the files; real if we depend.

Ramp-up

• Engineer ramp-up on PHPStan-style workflow is low (half a day for anyone who has used it). The real cost is first-run triage: someone must own reading the initial error wall, deciding genuine-bug vs. false-positive vs. baseline-entry. Budget 3–5 days of one senior engineer for a mid-sized Laravel codebase.
• Do not underestimate the social cost: a blocking analyser introduced without a baseline reads to the team as a tax on their existing work.

Recommendation

• Do not adopt as a live dependency. Score 0 and 0 dependents is a disqualifying signal for a package whose entire value is a static config file.
• Do extract it as a reference template if the preset encodes sane defaults faster than we could author them; otherwise start directly from larastan + a standard phpstan.neon.dist and skip the package entirely.
• Either way, the operational plan is identical: baseline, non-blocking observation, then shrink-only ratchet, with an internal owner named up front.