Php Quality Config Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The package remains a centralized quality-configuration bundle (PHPStan/Pint/PHPUnit rule sets) rather than a runtime library. Its value proposition is unchanged, but v2.5.0 shifts the package from "modern-stack enabler" to leading-edge-stack enforcer: it now targets teams already running PHP 8.5.
• Modularity: No new extension points are introduced in this release. The change is a constraint change only (composer.json platform requirement plus removal of the PHP 8.4 CI lane), so there is no new Laravel integration surface (service provider, config merge, facade) to evaluate. The package is still a dev-dependency config artifact, consumed via CI and local tooling.
• Laravel-Specific Synergies:
  • PHP 8.5 minimum effectively narrows the addressable Laravel range to Laravel 12+ on PHP 8.5. Laravel 11 (PHP 8.2–8.4) and Laravel 10 (PHP 8.1+) are now out of scope unless overridden.
  • No change in PHPUnit/PHPStan/Pint pinning is documented in this release, so the quality baseline is unchanged — only the interpreter floor moved.
• Risk introduced by this release:
  • Hard floor raise: Require PHP 8.5 is a runtime-breaking constraint shipped as a minor version bump (v2.4.0 → v2.5.0). Any project on a floating ^2.x constraint will be silently upgraded into an unsatisfiable platform requirement on the next composer update.
  • CI lane removal: dropping the 8.4 lane means the maintainers no longer test against PHP 8.4, so regressions affecting 8.4 users will no longer be caught upstream even if a consumer force-installs with --ignore-platform-reqs.
  • Ecosystem lag: PHP 8.5 is a recent runtime; PHPStan, Pint, PHPUnit, Xdebug/PCOV and base Docker images must all have 8.5-compatible releases for the package to be usable in CI at all.
  • Semver discipline: a platform requirement bump is conventionally a major change. Treating it as a minor elevates the importance of exact pinning in consumer composer.json.

Integration Feasibility

• PHP Version Compatibility:
  • PHP 8.5 becomes mandatory. PHP 8.4 — previously the documented floor and the recommended target in the last assessment — is now explicitly dropped from CI.
  • PHP 8.6 / future versions: unknown; no forward-compatibility statement is provided.
• Laravel Version Compatibility:
  • Laravel 12+ on PHP 8.5: the only fully supported combination.
  • Laravel 11.x: effectively blocked (PHP 8.2–8.4 ceiling on supported patch levels).
  • Laravel 10.x: blocked.
• Dependency Conflicts:
  • Consumer projects that pin php to 8.4.* in composer.json will fail resolution outright.
  • CI runners, Docker base images (php:8.5-cli), and hosting platforms must expose 8.5 before this package can be adopted — this is now the critical path, not the package itself.
  • Bundled tool versions remain a conflict vector with globally installed PHPStan/Pint, unchanged from the prior assessment.
• Configuration Override: unchanged. No new Laravel config helpers or runtime rule injection were added; teams still rely on static config files.
• Testing Integration: unchanged, but note that if the maintainers' 8.5 lane is the only tested lane, test-tooling regressions on 8.4 will go unnoticed.

Technical Risk

• Severity: Medium-High for existing consumers, Low for greenfield PHP 8.5 projects.
  • Blast radius: broad but loud — Composer fails fast on platform requirements rather than producing subtle runtime failures. This is a safe failure mode provided version constraints are exact.
  • Silent upgrade risk: floating ^2.0 / ^2.3 constraints turn a routine composer update into a build-breaking event. This is the single most actionable risk.
  • Support-window risk: with 8.4 support dropped after only one minor cycle, consumers cannot assume the floor is stable across minor releases.
• Performance Overhead: no documented change to analysis rule sets or tool versions, so no expected change to PHPStan/Pint runtimes. PHP 8.5 itself may yield modest runtime improvements, but this package affects CI duration, not application performance.
• Maintainership Signal: a single PR from a first-time contributor carries the entire release. There is no stated deprecation window, no changelog guidance on migration, and no LTS/backport branch announced. For a package that gates your CI, that is a governance risk worth flagging to the platform owner.
• Roadmap Uncertainty: whether a v2.4.x maintenance line will continue to support PHP 8.4 is unknown and decisive for teams that cannot move to 8.5 this quarter.

Key Questions

1. Is a PHP 8.4-compatible maintenance line (e.g. 2.4.x) going to be supported, and for how long? This determines whether teams can adopt v2.5.0 later or must fork/pin now.
2. Why was a platform-requirement bump released as a minor rather than a major? Is the project's semver policy documented, and should consumers pin exactly (2.4.1) rather than by range?
3. Which Laravel versions are officially in scope for PHP 8.5? Is Laravel 12.x the floor, and will Laravel 13 be validated?
4. Have the bundled tool versions (PHPStan, Pint, PHPUnit) been validated on PHP 8.5? Are there known incompatibilities at the pinned versions?
5. What is the CI matrix now? Is 8.5 the only lane, and is there any coverage for 8.4 users who force-install?
6. Are PHP 8.5-only language features now used in the shipped configs or scripts (e.g. new syntax in bootstrap scripts), which would make 8.4 unusable even with --ignore-platform-reqs?
7. What is the security/support policy — does dropping a CI lane also mean dropping security fixes for that PHP version?

Integration Approach

Stack Fit

• Laravel 12+ / PHP 8.5: Strong fit — this release is effectively built for that combination.
• Laravel 11 on PHP 8.4: No fit with v2.5.0. Requires pinning to 2.4.x or forking the config.
• Laravel 10: No fit.
• Multi-repo / microservice estates: Caution — a single shared quality-config package now imposes a uniform PHP 8.5 floor across every service. Services on staggered upgrade timelines will fragment the config into forked per-service variants.
• Non-Laravel PHP: unchanged; usable as a standalone config bundle, but now gated on 8.5.

Migration Path

1. Freeze and pin first (immediate)
   • Change the constraint from ^2.3 / ^2.0 to an exact version (2.4.x) in every consuming composer.json to stop silent upgrades into the 8.5 floor.
   • Add composer.lock review to PR checklists so platform-requirement changes surface in review.
2. Inventory the estate
   • Enumerate every repo consuming the package and record its PHP runtime version, Laravel version, and CI image.
   • Split into cohorts: already on 8.5 / can move this quarter / blocked.
3. Environment readiness before code changes
   • Verify CI runner images, Docker base images, and deployment targets offer PHP 8.5 with required extensions (Xdebug/PCOV for coverage).
   • Confirm pinned PHPStan/Pint/PHPUnit versions publish 8.5-compatible releases.
4. Pilot on one greenfield or already-8.5 repo
   • Install v2.5.0, run the full quality suite, record CI duration delta and any new rule failures.
5. Roll out by cohort
   • Cohort A (8.5-ready): upgrade to v2.5.0 in the same PR that moves the runtime, not before.
   • Cohort B (8.4): stay on the pinned 8.4-compatible line; track the maintainer's answer on maintenance-branch support.
   • Cohort C (blocked): no action beyond pinning; document the fork decision point if the 8.4 line is retired.
6. Fallback
   • Option A: pin to 2.4.x and monitor for a maintenance release.
   • Option B: fork the config into an internal php-quality-config package with an 8.4 floor, accepting ongoing maintenance cost.
   • Option C: revert to hand-maintained phpstan.neon / pint.json in blocked repos — lowest coordination cost, highest drift risk.

Compatibility

• PHP: 8.5 required. 8.4 explicitly de-supported at the maintainer's CI level. 8.2/8.3 unaffected (already excluded).
• Laravel: 12+ expected; 11 and below blocked by platform constraint.
• Tooling: bundled PHPStan/Pint/PHPUnit versions must be 8.5-capable; verify before rollout rather than after.
• Extensions: Xdebug/PCOV coverage support on 8.5 is the most likely gap in CI images.
• Semver contract: treat every minor release of this package as potentially breaking. Constraint strategy must reflect that.

Sequencing

• Do not pair this release with an unrelated dependency-refresh PR. Isolate it so failures are attributable.
• Order of operations: pin → inventory → image/runtime readiness → tool-version verification → single-repo pilot → cohort rollout.
• Gate: no cohort advances to v2.5.0 before its runtime is on 8.5 in both local-dev and CI. The package change should follow the runtime change, never lead it.
• Trigger for re-assessment: a v2.4.x maintenance release, or any statement of an LTS/backport policy.
• Dependency order within rollout: PHP 8.5 image → PHPStan/Pint verification → package upgrade → CI pipeline update → removal of legacy config files.

Operational Impact

Maintenance

• Constraint churn is now the primary maintenance cost. With the PHP floor moving 8.4 → 8.5 within one minor cycle, expect frequent platform-requirement changes; budget for a quarterly review of the pinned version rather than a set-and-forget dependency.
• Pinning discipline becomes mandatory. Floating ranges are not safe with this package's current release policy.
• Fork budget: if the 8.4 line is retired without a maintenance branch, the operational cost shifts to owning a fork — estimate ongoing effort as low code volume but non-trivial release-tracking overhead.

Support

• Single-maintainer contribution signal: a first-time contributor's PR constitutes the entire release. Escalation paths for breakage are thin; assume self-service resolution for anything beyond straightforward version pinning.
• Documentation gap: no migration or deprecation notes accompany the floor raise. Internal documentation is needed to record which repos are on which pinned version and why.
• Internal ownership: designate a named owner for the quality-config dependency so version decisions are not made ad hoc per repo.

Scaling

• The package scales well technically — it is a config artifact, not a runtime component, so it adds no application load.
• It scales poorly organisationally: a single shared floor forces synchronised PHP upgrades across every consuming repo. As the estate grows, this becomes a coordination bottleneck.
• Mitigation: allow per-repo pinning as a first-class, sanctioned pattern (a small compatibility matrix in the internal docs) rather than treating version divergence as debt.

Failure Modes

• Loud failure (good): composer install rejects the platform requirement. Build fails immediately, no ambiguity. This is the expected mode for most consumers on floating constraints.
• Silent upgrade failure (bad): an unattended composer update in a repo without an exact pin breaks CI with no apparent code change and no obvious cause. Highest-likelihood incident for this release.
• Untested-platform regression (medium): consumers who force-install on PHP 8.4 are running a configuration the maintainers no longer test. Failures would surface as confusing PHPStan/Pint errors, not clean platform rejections.
• CI infrastructure gap (medium): no 8.5 image or missing extensions causes failures that look like package incompatibility but are environment issues — expect this to consume the bulk of troubleshooting time during rollout.
• Drift failure (low, slow-burn): repos that opt out (fork or hand-maintained configs) gradually diverge in rule sets, producing inconsistent quality gates across the estate.

Ramp-up

• Low technical ramp-up: no new APIs, no new configuration surface. Engineers need only understand the version constraint.
• Moderate process ramp-up: teams must absorb the pinning policy, the compatibility matrix, and the "runtime first, package second" sequencing rule.
• Highest-effort activity is environmental, not code: getting PHP 8.5 into CI images, local dev containers, and deployment targets.
• Estimated timeline: 1 day for pinning and inventory; 1–2 weeks for image/tooling readiness; 1–2 weeks for cohort rollout. Blocked cohorts should be explicitly deferred with a documented decision date rather than left ambiguous.
• Recommendation: adopt v2.5.0 only in cohorts already on PHP 8.5; pin everything else to the last 8.4-compatible release and re-assess when the maintainer clarifies the support window for that line.