Php Standard Laravel Package

Product Decisions This Supports

• Framework upgrade timing (the headline item). v2.3.0 adds Laravel 12 support. This is the gate that typically blocks a Laravel 11 → 12 upgrade when a shared standards/tooling package pins or constrains framework versions. If your roadmap has a Laravel 12 migration, this release removes a dependency-level blocker and lets you sequence the upgrade into the next cycle rather than deferring it.
• Vendor/maintenance risk tracking. A versioned, changelogged release with a compare link is a positive health signal from TenantCloud. It de-risks the "abandoned internal package" scenario and argues for keeping the dependency rather than forking it — at least through the Laravel 12 window.
• Build vs. buy for code standards. Adopting a maintained external standard is cheaper than owning a custom PHPCS/Pint/static-analysis ruleset across repos. This release is a data point that the "buy" path is still being maintained upstream, so it lowers the case for building an in-house ruleset now.
• CI consistency decisions. If multiple repos share this standard, the release supports standardizing CI across services on one pinned major/minor and rolling upgrades centrally instead of per-team.
• Low-risk adoption decisions. No breaking changes are announced in this release note, which supports a "patch/minor bump and re-run CI" decision without a migration project.

Caveat: this assessment is based on release metadata (version + headline feature + changelog link) only — no README, rule diff, or dependency constraints were reviewed. Treat the compatibility claim as a signal to validate, not a verified guarantee.

When to Consider This Package

Consider adopting or upgrading when:

• You are planning or running a Laravel 12 migration and this package is a transitive or direct dependency blocking it — v2.3.0 is the version to target.
• You run multiple Laravel repos/teams and want one enforced style/standards ruleset rather than drift between projects.
• You already align with (or can accept) TenantCloud's conventions and want lower review overhead on formatting and static-analysis nitpicks.
• You want vendor-maintained tooling you can track with semver and changelogs, rather than a bespoke internal ruleset.
• You are on Laravel 12 and evaluating a shared baseline for new services (greenfield standardization).

Look elsewhere or hold when:

• You are on Laravel 10/11 with no near-term 12 plans — there is no functional benefit to rushing this bump; batch it with the framework upgrade.
• You need framework-version-agnostic tooling, or you maintain Lumen/legacy/older Laravel apps alongside 12 — check whether this minor drops older-version support before pinning.
• A minor bump silently changes rules. "Standard" packages often ship rule changes in minors; if your CI enforces these, an unvetted bump can generate churn. Pin exact versions and diff the ruleset before upgrading.
• You are a single small app where Laravel Pint's defaults plus PHPStan are sufficient — the added dependency and external convention set may not pay for itself.
• You require heavy customization of rules — a fork or your own ruleset is likely less painful than overriding a vendor standard.

How to Pitch It (Stakeholders)

For executives (one paragraph): The shared code-standards package we depend on shipped v2.3.0 with Laravel 12 support. In plain terms: the thing that would have held us back from a timely framework upgrade is now cleared, at no cost and with no migration work. It also confirms the upstream vendor is still actively maintaining the package, so we are not accumulating dependency risk. Recommendation: schedule the Laravel 12 upgrade in the next planning cycle and take this bump as part of it — no new budget or headcount required.

For engineering (short brief): v2.3.0 is an additive compatibility release for Laravel 12; no breaking changes are called out in the notes. Actions: (1) pin to 2.3.0 explicitly rather than floating on ^2; (2) diff the ruleset/changelog before merging, since standards packages can change rules in minors and we do not want surprise CI failures; (3) confirm our supported Laravel range still matches what this release supports before we drop any older-version support; (4) run a full CI pass on one representative repo as a canary before rolling to all repos. Treat the Laravel 12 claim as validated only after that canary is green.