Php Quality Config Laravel Package

Product Decisions This Supports

• Standardization of Quality Gates (narrowed platform target): The shared quality configuration still enforces consistent metrics (PSR compliance, complexity, static analysis, test coverage), but v2.5.0 raises the floor to PHP 8.5 and drops the PHP 8.4 CI lane. Quality standardization now only applies to projects already on — or committed to — PHP 8.5, which shifts this from "adopt broadly" to "adopt deliberately."
• PHP Version Roadmap Becomes a Hard Dependency: This package is now a forcing function for PHP 8.5 migration rather than a compatibility layer. Product/roadmap decisions about upgrade timing must be made before adoption, not after — the tooling no longer lets a team straddle 8.4 and 8.5.
• Accelerated Onboarding (conditional): Pre-configured PHPStan, Psalm, and Pest checks still reduce ramp-up time and dependency overhead — but only for teams whose runtime already satisfies PHP 8.5. Onboarding benefit is real; eligibility is now the gating question.
• DevOps/CI/CD Integration: Simplifies pipeline configuration and removes a maintenance lane (8.4) from CI, which is a direct reduction in build matrix cost and flakiness surface. The tradeoff is that any project still on 8.4 loses a supported path and must either pin to v2.4.x or upgrade PHP.
• Build vs. Buy: Still favors buy for teams on PHP 8.5 — upstream absorbs tooling churn. However, the maintenance burden partially transfers back to you if you must hold a mixed-version portfolio, since you'll need version pinning strategy per project (v2.5.x for 8.5, v2.4.x for 8.4).
• Roadmap Alignment:
  • Accelerates a PHP 8.5-first posture across Laravel services; deprioritizes 8.4 as a supported target.
  • Aligns with the maintainer's aggressive upstream tracking (single-maintainer-driven version bumps), which implies fast-moving minimum requirements — plan for this cadence.
  • Introduces a portfolio fragmentation risk for organizations running multiple PHP minor versions simultaneously.

When to Consider This Package

• Adopt if:
  • Your project runs PHP 8.5 (or is scheduled to before your next quality-tooling refresh).
  • You want standardized, low-maintenance quality checks without hand-rolling PHPStan/Psalm/Pest configuration.
  • Your CI matrix can drop the PHP 8.4 lane without stranding services.
  • You value developer velocity and upstream maintenance absorption over bespoke rules.
  • You're comfortable with AssoConnect's ecosystem (MIT license, shared tooling conventions).
• Look Elsewhere if:
  • Your stack is PHP 8.4 or earlier — v2.5.0 explicitly requires 8.5. You must pin to v2.4.x or defer adoption. Note the prior assessment listed PHP 8.4 as a supported target; that is no longer true at HEAD.
  • Your stack is non-PHP/Laravel (Node.js, Python, etc.).
  • You need highly customized quality rules (bespoke PHPStan/Psalm rules) or per-project divergence.
  • You run a mixed PHP version portfolio and cannot afford per-project version pinning overhead.
  • Community adoption / bus factor is a governance concern — this release came from a first-time contributor bumping a hard minimum version, which is worth flagging in vendor review.
  • You're bound by enterprise tooling (e.g., SonarQube) or strict, slow-moving PHP version constraints.

How to Pitch It (Stakeholders)

For Executives:

"The latest release (v2.5.0) focuses our quality tooling on PHP 8.5 only — it drops the PHP 8.4 CI lane and requires 8.5. That's a deliberate simplification: one supported platform, less CI surface, fewer flaky paths. The decision it forces is a timing decision, not a tooling decision: adopt when our Laravel services are on 8.5, or pin to the previous line (v2.4.x) until they are. It remains MIT-licensed with zero lock-in, and the upgrade is a one-line constraint change per repo. Recommendation: sequence this behind our PHP 8.5 migration, not ahead of it — otherwise we pay for coordination across a split-version portfolio."

For Engineering:

*"v2.5.0 is a breaking platform change: require PHP 8.5, and the 8.4 CI lane is gone. Practical impact:

• Any repo on 8.4 must stay pinned to v2.4.x; do not let a floating constraint pull v2.5.0 in.
• Repos on 8.5 can adopt v2.5.0 and get a smaller CI matrix — fewer lanes, less runtime, fewer version-specific false positives.
• Check your constraint style: use ^2.4 carefully — confirm whether it resolves to 2.5 and breaks the 8.4 lane, or pin explicitly. Tradeoffs: we lose the ability to run a single tooling version across a mixed 8.4/8.5 fleet, and we inherit the maintainer's cadence of hard minimum-version bumps (this one landed from a first-time contributor, which is a governance data point, not a blocker). Suggested action: inventory PHP versions across Laravel repos, pin 8.4 repos to v2.4.x, pilot v2.5.0 on one 8.5 service, and measure CI minutes saved before rolling out."*