Shoppingcart Laravel Package

Technical Evaluation

hardevine/shoppingcart is a community-maintained fork of the long-standing Crinsane/LaravelShoppingcart package. It is a session-backed cart primitive: a Cart facade over a session-stored collection of line items, with a small API (add, update, remove, content, total, subtotal, tax, destroy, store/restore), item-level and cart-level "conditions" for discounts/vouchers, and one level of nested child items. It is deliberately narrow: no persistence layer, no product/stock/price models, no currency model, no checkout, no order state machine. It is a calculator with a session store, not a commerce engine.

Change since last assessment (v3.4): the release note is a single line — "Supports L12." No new features, no API changes, no deprecations announced. This is a compatibility-only release and does not alter the package's shape or our integration design. It does partially close one open question (framework support) and is a mild positive signal on maintainer cadence, since it landed in step with the current Laravel major. Treat it as a maintenance signal, not a capability change.

Architecture fit

Integration feasibility — High, and marginally improved by 3.4: on a Laravel 12 codebase we can now consume the package on its current release line rather than pinning to an older frame. Composer install, package auto-discovery, one published config file (config/shoppingcart.php: tax rate, number/number format, conditions). No migrations, no queues, no credentials. A working cart is achievable in a single spike session.

Technical risk

Key questions

1. Which Laravel and PHP versions are in the supported CI matrix? Partially answered by 3.4: Laravel 12 is supported. Remaining: which exact PHP versions are covered (8.3/8.4 on the L12 CI job), is Laravel 11 still supported in the same release line or was it dropped, and what is the deprecation policy for older majors?
2. Is 3.4 a clean drop-in for our current pin, or does the L12 support come with a minimum Laravel/PHP constraint bump that forces an upgrade of surrounding packages?
3. How divergent is the fork from Crinsane/LaravelShoppingcart — is it a drop-in replacement, and will fixes be upstreamed or stay local?
4. Is there a documented rounding/money strategy, or is the expectation that consumers use integer minor units and format at the edge?
5. Can conditions be composed predictably (order of application, before/after tax) and evaluated per line vs. per cart?
6. What is the intended pattern for authenticating carts across devices and for merging a guest cart on login?
7. How stale-price and out-of-stock items are meant to be handled at checkout — does the package have any hooks, or is it entirely the integrator's job?
8. Is there a maintainer response SLA, security disclosure process, or release cadence we can plan upgrades against? (Weakly positive: a timely L12 release suggests cadence exists; still no published SLA.)
9. Does the package expose events we can hook for analytics (add-to-cart, abandonment), or must we instrument our own service layer?

Integration Approach

Stack fit — Best suited to a conventional Laravel monolith using the default session driver, Blade/Livewire checkout, and a server-side catalogue. If our target is a decoupled SPA or mobile client, I would not adopt this package as-is; the session coupling would force a custom persistence/identification layer that erodes the time saved. With 3.4, a Laravel 12 monolith is now a first-class target rather than a stretch.

Migration path

1. Adopt behind a boundary. Do not let Cart:: calls leak into controllers and views. Define an application-level CartService/CartRepository interface with our own DTOs (line item, totals, applied adjustments) and implement it using hardevine/shoppingcart. This is the single most important decision — it makes the package replaceable if pricing or multi-currency requirements outgrow it. A compatibility-only release like 3.4 is exactly the scenario this boundary is designed to absorb.
2. Make prices explicit. Convert catalogue prices to integer minor units at the boundary, and treat the package's stored values as display-only. All authoritative totals must be recomputed in our pricing service at checkout.
3. Persist a cart identity, not a cart. Store a cart key against the user/guest record in our own table; use store()/restore() for login merge and cross-device continuity. This gives us abandonment analytics and recovery without forking the package.
4. Revalidate at checkout. Snapshot price, tax, and availability at add-time for UX; re-resolve at order creation and surface diffs to the user. Never let the session cart be the source of truth for charge amounts.
5. Extend, don't patch. Implement multi-currency, tiered pricing, and complex promotions in our own condition/pricing layer that feeds the cart, rather than editing vendor code. Vendor patches must survive composer update.

Compatibility — Three compatibility axes now matter: (a) the framework/PHP matrix — 3.4 confirms Laravel 12, PHP matrix unconfirmed; (b) whether the L12 support bump is a hard constraint change (composer require floor moved) that ripples into our dependency set; and (c) compatibility of the fork with the ecosystem's existing documentation and Stack Overflow answers, which overwhelmingly describe upstream Crinsane behaviour. Expect namespace differences (Hardevine\Shoppingcart\Facades\Cart) and some API drift versus older tutorials; budget time for that during onboarding. Pin to ^3.4 on a Laravel 12 codebase; if we are still on Laravel 11, confirm the previous minor remains installable before sequencing the framework upgrade.

Sequencing (typical 3–5 sprint engagement, cart-only scope)

No resequencing is required by 3.4; it only removes the "will this work on our framework version" unknown from Phase 0.

Operational Impact

Maintenance — Low day-to-day cost and low upgrade cost: a handful of classes, no schema, no migrations, no background jobs, no infrastructure. The real maintenance is ours: the adapter, pricing layer, and merge logic. Two ongoing obligations: track package releases against our Laravel upgrade cadence, and keep our pricing logic separate so a fork going quiet is a contained, not existential, problem. 3.4 is a good data point for the first obligation — record it in the upgrade log and pin the new floor.

Support — MIT with no commercial backing and no SLA. Support is GitHub issues plus reading source. Given the high "opportunity" signal and minimal downstream dependents, we should assume we may need to vendor-patch. Budget a named owner (roughly 5–10% of one engineer) for upstream triage; treat the fork's bus factor as a tracked risk with a documented exit path (swap the adapter to an in-house implementation). The L12 release is reassuring on cadence but does not change the absence of a support commitment.

Scaling — No scaling cost from the package itself, and none added by 3.4. Session-backed carts still constrain horizontal scale: we need shared session storage (Redis or database sessions) and sticky-session-free routing. Session payload grows with cart size and nested items — keep carts small (cap line count, avoid unbounded child items) and monitor session size, since large serialized carts increase Redis/DB session I/O and cookie/response overhead. Analytics and abandonment reporting are not available from the session store and must come from our own cart-identity table.

Failure modes

Ramp-up — A mid-level Laravel engineer reaches productivity in roughly half a day: the API is small and the config is one file. The non-obvious parts — nested/child items, condition ordering, tax application semantics, and store()/restore() behaviour — need a short internal write-up and a handful of tests to become team knowledge. The steeper learning curve is not the package but the pricing/rounding discipline we impose around it; that belongs in onboarding docs, not in the developer's head. Nothing in 3.4 changes this.

Recommendation — Adopt for a conventional Laravel monolith cart, wrapped behind our own interface, with integer money and checkout revalidation owned by us. Version 3.4 (Laravel 12 support) removes the framework-support caveat on a current Laravel codebase and is a mild positive on maintainer cadence, but it is a compatibility release only and does not narrow the package's structural limits. Do not adopt as the system of record, and re-evaluate if multi-currency, headless clients, or complex promotion rules become requirements — at that point the adapter should be replaced rather than the package forked.