Bold Shopify Toolkit Laravel Package

Product Decisions This Supports

• Platform upgrade planning. 8.0.0 is an enablement release: it unblocks PHP 8.5 and Laravel 13 in our stack. It adds no product capability — its value is keeping us on supported runtimes rather than falling behind vendor support.
• Build vs buy. The release itself is the argument for buying: PHP deprecation cleanup (setAccessible() removal, explicit nullable types) and regression testing against Shopify Admin API 2026-07 (SHOP-12163) is maintenance work we would otherwise own in a bespoke client.
• Commerce feature scoping. The touched surfaces — Cart, Asset, Client, Base — map to cart/checkout and asset handling. If roadmap work lands on cart or product assets, this package is the substrate and is being actively maintained.
• Dependency policy. A major bump with (per the notes) no functional changes supports a "stay within one major of upstream" policy and lets us schedule the upgrade as routine maintenance rather than a project.
• Risk register. The tag is byte-identical to beta.6, regression-tested, which is a strong signal. But 8.0.0 is the first stable of the line; it warrants a normal verification pass, not an elevated one.

When to Consider This Package

Adopt or upgrade when:

• We're on, or moving to, Laravel 12/13 and PHP 8.4/8.5 — the widened illuminate/support constraint (^12 || ^13) and nullable-type cleanup exist precisely for that matrix.
• We need a maintained, Laravel-native Shopify Admin API client and don't want to own auth, resource modelling, and API-version churn.
• We subclass Asset, Base, Cart, or Client: audit overridden signatures first. Implicit nullable parameters are now explicit, and a mismatch in a child class is a fatal error rather than a deprecation notice.
• We run CI on PHP 8.3 or Laravel ≤11: 8.x likely won't resolve. Staying pinned to 7.x is a legitimate choice, but make it explicitly — that line is now off the supported path.

Look elsewhere or defer when:

• We have unmet functional requirements. This release is compatibility work only; nothing new is shipped.
• We cannot absorb a major version this quarter. The change is small but it is not patch-level, and pinning should be a stated decision, not a default.
• We only need a handful of read-only endpoints — a thin HTTP client may be less surface area than a full resource layer.

How to Pitch It (Stakeholders)

Executives: This is maintenance, not a feature release. It keeps our Shopify integration on current PHP and Laravel so we stay inside vendor support and security-patch coverage. No customer-facing change and no expected behaviour change. Cost is one upgrade ticket plus regression on cart and checkout paths — small, plannable, and materially cheaper than maintaining our own Shopify client. Recommendation: schedule it alongside the next framework upgrade rather than as a standalone project.

Engineering: 8.0.0 is the promotion of 8.0.0-beta.6, byte-identical to that tag and regression-tested against Shopify Admin API 2026-07 (SHOP-12163). Changes: explicit nullable parameter types across Asset, Base, Cart, Client (implicit nullable is deprecated from PHP 8.4); removal of the no-op ReflectionProperty::setAccessible() in Base::unserializeModel(); illuminate/support widened to ^12 || ^13 (SHOP-8855, #183). Actions: audit subclasses of those four classes for signature compatibility, confirm our PHP/Laravel matrix resolves against the new constraint, and run the existing Shopify integration suite — the Admin API version alignment is the part that actually carries risk.