Laravel Builder Macros Laravel Package

Product Decisions This Supports

• Framework/platform roadmap: v2.0.0 is explicitly a Laravel 10 compatibility release, so this package is now a candidate for the Laravel 10 migration program rather than a blocker. Add it to the dependency readiness tracker and confirm whether it also still supports Laravel 8/9 — that determines whether it can sit on the migration critical path or must be upgraded in lockstep.
• Build vs. buy / dependency selection: A major version dedicated to framework support is a positive maintenance signal (someone is actively tracking upstream), but it is a compatibility release, not a feature release. Do not treat it as evidence of roadmap investment; treat it as evidence the package is not abandoned. Weight accordingly when comparing against an in-house implementation.
• Upgrade cost budgeting: Semver-major almost always means breaking changes for consumers, even when the changelog only mentions the framework. Reserve engineering time for an upgrade spike and version-constraint review before committing to v2.
• Platform standards (PHP floor): Laravel 10 requires PHP 8.1+. Adopting this release implicitly pulls the PHP minimum forward, which touches CI images, hosting/runtime images, and any shared libraries pinned to older PHP. This is a platform decision, not a package decision.
• Support-window and EOL planning: If v2 drops Laravel 8/9 support, anything still on an older LTS is stranded on v1.x and will stop receiving fixes. Flag those applications for a forced upgrade or a documented exception.

When to Consider This Package

Consider it when:

• You are on or moving to Laravel 10 and want a dependency with confirmed upstream framework support.
• You need a maintained third-party component rather than owning the maintenance burden in-house.
• You can absorb a major-version upgrade (or you are already on v1 and the jump is small — verify the diff before assuming).
• Your team is already on PHP 8.1+, so the version bump does not cascade into runtime/infrastructure work.

Look elsewhere or defer when:

• You are pinned to Laravel 9 or earlier and cannot move — check first whether v2 still supports your version; if not, you are on a dead-end branch.
• The v2 changeset turns out to be broad (framework work often carries incidental API changes). If your integration surface is large, a vendored/forked approach may be cheaper than repeated upgrade churn.
• Release cadence matters more than this one release: "prepare for Laravel 10" is a catch-up signal, not a ahead-of-the-curve signal. If you need same-day support for future Laravel majors, verify the maintainer's track record rather than inferring it from a single release.
• You need guaranteed SLAs or long-term support commitments — a single major version note tells you nothing about governance, bus factor, or security-response policy.

Verify before deciding (not established by this release): actual breaking-change list, whether Laravel 8/9 support is retained, test coverage/CI matrix, maintainer count and activity, and open-issue responsiveness.

How to Pitch It (Stakeholders)

For executives: A dependency we rely on has shipped a major release to support Laravel 10. That is good news for platform risk — it means the component is being maintained and will not block our framework upgrade. The cost is that a major version implies upgrade work on our side, plus a minimum PHP version of 8.1 across affected services. Recommend: approve a short upgrade spike, not a full commitment, and require the team to report back on breaking changes and the PHP floor before we schedule the migration.

For engineering: Treat v2.0.0 as a compatibility milestone, not a feature drop. Before upgrading: read the full changelog and diff (the note only covers Laravel 10 readiness), confirm whether Laravel 8/9 are still supported, audit our usage against any changed APIs, bump PHP to 8.1+ in CI and runtime images, and pin the constraint deliberately rather than floating to ^2.0. If the upgrade is non-trivial, we keep v1 pinned on a documented exception with a dated review.