Laravel Cart Laravel Package

Product Decisions This Supports

• Build vs. buy on commerce primitives. v3.0.0 materially changes this calculus: first-class Coupon, TaxRule, and ShippingRate abstract classes mean coupons, tax, and shipping logic no longer has to be hand-rolled as ad-hoc CartCondition arrays. That removes a chunk of the "we'd have to build it ourselves anyway" argument for greenfield carts.
• Roadmap sequencing for commerce features. The driver system (SessionDriver, DatabaseDriver, RedisDriver, NullDriver, MultiDriver) lets you ship a session-backed cart for MVP and migrate to persistent, multi-device carts later without re-architecting the cart domain. That is a genuine roadmap de-risker and worth planning the migration path around now.
• Abandoned cart, cross-device, and logged-in/guest merging. These features are only credible if the cart is persisted outside the session. DatabaseDriver / RedisDriver / MultiDriver make these a config decision rather than a rewrite — treat them as newly feasible roadmap items.
• Frontend stack choice. HasCart (Livewire reactive properties) and ShareCartWithInertia (Inertia shared props) mean cart UI is no longer a reason to pick one frontend stack. This unblocks the "Livewire vs. Inertia/Vue" decision to be made on other grounds.
• Test strategy and quality bar. Cart::fake(), CartFactory with withItems() / withCondition() / withCoupon(), and the assertion set (assertTotal(), assertConditionApplied(), etc.) mean cart behavior is testable without hitting session or DB. Budget for checkout/cart tests drops, and this is the single strongest signal of production-readiness in the release.
• Team velocity and onboarding. cart:install plus cart:make:coupon|tax|shipping|driver generators impose a conventional app/Cart/ structure. That's a real architectural opinion — decide whether to adopt it or fight it.
• Promotional mechanics. applies_to (limit a condition to the first N units of a line item) directly enables "buy 2 get 1 free", tiered BOGO, and per-unit discount campaigns that previously required custom condition code.
• Migration cost as a planning item. This is a major version. CartSession is removed, the Cart constructor signature changed (driver instead of raw storage), and the config publish tag was renamed config → cart-config. Container-resolved usage is unaffected, but any code that instantiated Cart directly, type-hinted CartSession, or scripts vendor:publish --tag=config will break. Scope this before committing to the upgrade.
• Not a decision driver: PHPStan level 5 and Laravel 13 support are hygiene, not strategy. They reduce the "is this maintained?" objection but shouldn't move a build-vs-buy call on their own.

When to Consider This Package

Consider adopting when:

• You're building a Laravel commerce surface that isn't the core business — internal ordering, SaaS add-on purchases, seat/plan upgrades, donations, marketplace line items — where a full commerce platform (Shopify, Stripe-native checkout, Medusa, Saleor) is overkill and headless would cost more than it saves.
• Your product needs a cart, not a checkout. This package solves cart state, conditions, totals, coupons, tax, and shipping rates. It does not solve payment orchestration, PCI scope, refunds, subscriptions, or fulfillment. If payments are the hard part, you're adopting it for the easy half.
• You want server-authoritative totals rather than computing prices in the browser. The condition/total pipeline being server-side is a correctness and fraud win.
• Your stack is Livewire or Inertia — the v3 integrations are now a real reason to pick it over a generic cart library.
• You expect to grow from session carts to persistent carts and want that door open from day one.
• You're upgrading from v2 and can absorb a major-version migration with a defined window; the additive features are substantial enough to justify the churn.

Look elsewhere when:

• You need multi-currency with historical FX, tax calculation (nexus, VAT/OSS, exemptions), or shipping carrier rate negotiation. This package models tax and shipping as conditions you supply — the hard logic is still yours. Evaluate TaxJar/Stripe Tax and EasyPost/Shippo alongside it.
• You need catalog, inventory reservation, or order management. This is a cart, not a commerce platform. Don't stretch it into one.
• You're on a non-Laravel or non-PHP stack, or you're standardizing commerce across multiple services — a headless commerce backend will serve you better than a per-app library.
• You need subsidized/enterprise support, SLAs, or long-term vendor commitment. This is a single-maintainer package (@joelwmale is the sole contributor on v3.0.0). That's the largest strategic risk in this assessment and should be priced accordingly: assume you may own the code.
• Your pricing model requires complex promotion engines — stacking rules, priority resolution across dozens of overlapping campaigns, spend-threshold ladders. Conditions are ordered but a rules engine this is not.
• You're on a frozen Laravel version below the supported floor or can't take the v3 constructor/config-tag breakage in the current cycle.

How to Pitch It (Stakeholders)

For executives: This release turns a utility cart library into a credible foundation for our commerce surface. Previously we'd have hand-built coupons, tax, and shipping as loose condition objects; v3.0.0 gives us typed, extendable Coupon/TaxRule/ShippingRate classes and a storage layer that lets us start session-based and graduate to persistent, cross-device carts without a rewrite. Two things to weigh: it is still a single-maintainer open-source package (so we should assume some ownership risk, and keep the abstraction thin enough to swap), and it deliberately does not handle payments, tax calculation, or carrier rates — those remain buy decisions. My recommendation is to adopt for cart state and totals, integrate Stripe/TaxJar/carrier APIs behind its condition interfaces, and treat the storage driver system as the insurance policy that keeps our exit cost low.

For engineering: v3.0.0 is a major release with real breaking changes, but they're narrow. CartSession is gone, replaced by the CartDriver interface and CartManager; the Cart constructor now takes a driver rather than raw session/database storage; and the config publish tag moved from config to cart-config. Service-container usage is explicitly unaffected, so audit for direct Cart instantiation, CartSession type-hints, and publish scripts before scheduling the bump. In exchange you get a genuinely better test surface — Cart::fake() swaps in an in-memory NullDriver and hands back a CartFactory for fluent state seeding, with assertions covering contents, counts, quantities, subtotals, totals, and applied conditions — plus Artisan generators (cart:install, cart:make:coupon|tax|shipping|driver) that standardize an app/Cart/ layout. Conditions are now serialized to arrays before storage, which fixes cross-driver serialization drift and is worth double-checking against any custom condition classes that relied on object identity. Also note the Redis driver TTL bug fix (minutes → seconds): if we're on Redis, existing keys were written with wrong expiries and should be validated. PHPStan level 5, zero errors, and Laravel 13 support are in place. The one thing I'd push back on: the single-maintainer bus factor means we should keep our Coupon/TaxRule/ShippingRate subclasses and condition logic in our own namespace, not vendored into the package's structure, so a fork or replacement stays a weekend, not a quarter.