Product Decisions This Supports
- Build vs. buy for basket/cart primitives. This package covers the undifferentiated plumbing of a basket (persistence, polymorphic ownership, quantity merging, item retrieval, clearing) so PM capacity can be spent on pricing, promotions, and checkout differentiation instead of re-implementing cart CRUD.
- Framework modernization roadmap. v6.1.0 explicitly supports Laravel 5.5 through 13 with a passing CI matrix. That means the basket layer no longer blocks a Laravel 11/12/13 upgrade — it can be treated as a solved dependency in the platform upgrade plan rather than a migration workstream.
- Feature sizing for cart-adjacent epics. The new
add() return value (the created or quantity-merged item) and one-query clear() shorten the work needed for "add to cart" response payloads, optimistic UI updates, and "empty basket" flows — useful inputs when estimating cart/checkout stories.
- Guest vs. authenticated basket strategy. Polymorphic basket ownership plus morph-map alias storage supports the common product decision to let anonymous shoppers build a basket and later attach it to an account, without a bespoke ownership model.
- Data-integrity policy decisions. Rejecting unsaved basketable models with a clear exception and safely skipping orphaned polymorphic rows are explicit product-facing rules: baskets cannot reference unsaved or deleted catalog objects. That reduces "ghost item" bugs reaching customers.
- Catalog deletion / lifecycle decisions. The clear error on requesting an orphaned item's price makes it a first-class, observable condition — supporting decisions about what a shopper sees when a product is removed mid-session (drop the line vs. flag it), rather than silent nulls.
- Runtime and hosting constraints. The lowered PHP floor (7.1 actual requirement) widens deployment options for legacy or cost-constrained environments, and can inform decisions about when to retire older PHP hosts.
When to Consider This Package
Adopt when:
- You are on Laravel (5.5–13) and need a basket/cart persistence layer, not a full commerce platform.
- The domain is simple to moderate: line items with quantities, polymorphic owners (user, guest, session, tenant), merge-on-duplicate, clear-all.
- You want a small, dependency-light package where the maintenance burden sits with the vendor and platform upgrades are already proven by CI.
- You are planning a Laravel upgrade and want one fewer package blocking the path.
- Your team is small and would otherwise write this layer as homegrown, untested code.
Look elsewhere (or build in-house) when:
- You need checkout, payments, tax, shipping, or discounts/promotion engines — this is not that package; assume those remain your responsibility.
- You need distributed or high-concurrency cart semantics (multi-region writes, heavy contention, cross-device real-time sync) that a single-database Eloquent model won't satisfy.
- You require first-party vendor support, SLAs, or security certification — an open-source package with community maintenance won't carry that.
- You need complex line-item modeling (bundles, kits, configurable products, per-line metadata schemas, price history/audit trails).
- You are not on Laravel/PHP, or your stack's conventions would conflict with Eloquent-based polymorphic relations.
How to Pitch It (Stakeholders)
For executives: v6.1.0 is a low-risk, compatibility-focused release with no breaking API changes. It extends support across Laravel 5.5 through 13, which removes a blocker from our framework upgrade path and lets us defer or avoid a costly cart rewrite. The functional additions — auto-saving a basket on first item add, returning the created or merged item, one-query basket clearing, and explicit errors for removed catalog items — directly reduce cart bugs and small feature work. Build-vs-buy favors continuing to depend on this package for cart plumbing while we invest engineering in pricing, promotions, and checkout.
For engineering: minor-version bump, semver-compatible. PHP runtime floor set to the real requirement (7.1), Laravel 13 added, Travis/Coveralls replaced with a passing GitHub Actions matrix spanning 5.5–13, plus fixed test migrations and Artisan command setup — i.e., the test suite now actually proves the compatibility claim. Two behavior changes to regression-test rather than assume: add() now returns the created or quantity-merged item (previously likely void/boolean), and a manually constructed basket persists itself on first item add. Also new: unsaved basketable models throw instead of silently persisting, morph-map aliases are stored when available, orphaned polymorphic rows are skipped during matching, clear() deletes all items in one query, and orphaned item price access raises a clear error. Add regression coverage for any caller relying on add()'s old return, for baskets constructed without an explicit save, and for product-deletion edge cases.