Laravel Cart Laravel Package

Product Decisions This Supports

• Build vs. buy for cart mechanics. The cart is commodity scope: store an item, change quantity, remove it, total it. This package collapses that into a facade plus one interface on your Product model, so the decision shifts from "how many sprints to build a cart" to "do we accept the constraints." That frees engineering capacity for the parts of commerce that actually differentiate — pricing rules, promotions, checkout flow.
• Roadmap scoping for MVP vs. full commerce. The declared ToDo list is effectively a gap analysis of what you still have to own: stock validation before add, cart events (ItemAdded/ItemRemoved), guest→user cart merge, expired-session cleanup, item-count and total-quantity helpers. Each unchecked box is a work item your team must schedule or consciously defer. This is the single most useful artifact in the repo for planning.
• Guest-checkout and pre-login funnel decisions. Native support for guests (session-backed) alongside authenticated users, plus configurable guards, means "let people add to cart before they have an account" is a configuration choice rather than an architecture change. That's a conversion-relevant product decision you can make cheaply.
• Admin, support, and impersonation use cases. setUser() and setGuard() allow operating on someone else's cart — support agents rebuilding a lost cart, sales reps assembling an order for a customer, QA seeding states. This enables product surface area (an internal "rebuild this cart" tool) that would otherwise need bespoke code.
• Pricing integrity as a first-class requirement. BCMath arithmetic with string-typed returns signals the package treats money as money, not floats. That supports a product commitment to accurate totals and tax-inclusive/exclusive display without asking engineering to hand-roll decimal math.
• Storage and infrastructure choices. Database vs. session driver is a config decision with real product consequences: persistence across devices (database) versus frictionless anonymous carts with no write amplification (session). Worth deciding explicitly per market.
• Vendor lock-in posture. A custom driver can be registered via Cart::extend(), and the Driver contract is small. That means "adopt now, replace the internals later" is a credible path — you can keep the facade surface your controllers depend on while swapping implementation, which lowers the cost of an early bet.

When to Consider This Package

Consider it when all of the following hold:

• You are on a Laravel version the package actually supports. Verify this first: release 1.0.1 pins illuminate/support to ^13, and no compatibility matrix is published. On Laravel 11/12 you must deliberately pin an earlier tag rather than let Composer resolve.
• Cart scope is genuinely simple: single currency, price × quantity totals, tax-inclusive or tax-exclusive display, no per-line promotions, no bundled products, no tiered or volume pricing. The package totals line items; it does not model discount engines.
• Your Product model can cleanly implement CartItemProduct — realistically meaning you can express price and tax as numeric strings from one model. If pricing lives across variants, price lists, or region-specific tables, the mapping gets awkward fast.
• Your users table uses bigint IDs, or you are willing to edit the published migration before running it. UUID/ULID primary keys require a migration change; catching this after php artisan migrate is a data problem.
• You are willing to own the missing pieces in-house: stock validation, cart events, guest→user merge on login, and stale-cart cleanup are all still unchecked on the ToDo list. None are exotic, but none are free.

Look elsewhere, or build, when:

• Dependency risk tolerance is low. Zero stars, zero dependents, no third-party production track record. For code sitting between a customer and a payment, that is the headline risk, not a footnote.
• You need events for downstream systems. Without ItemAdded/ItemRemoved, abandoned-cart email, analytics funnels, and inventory reservation hooks must be wired manually at every call site — and that wiring drifts.
• Guest→user cart merge is a launch requirement. It is unimplemented. Users who add items anonymously and then log in will hit whatever behavior the default driver produces; design and test this before committing.
• Promotions, coupons, or complex tax are core. Not modeled. You would be building them on top of a total-price abstraction that may not accommodate them.
• You need a maintained, supported dependency with an SLA or a community to escalate to. This is a small-vendor package; support is best-effort.

Two verification steps before any commitment: confirm the release timeline is real and current (the listed last release is dated in the future — treat that as a signal to check Packagist directly rather than trust the summary), and run composer show isapp/laravel-cart to confirm the resolved version against your framework.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package that supplies standard shopping-cart mechanics — add, update quantity, remove, total — with correct decimal math and support for both guest and logged-in shoppers. Adopting it removes roughly the commodity portion of cart work from the roadmap and lets the team spend that time on checkout, pricing, and conversion instead. The trade-offs are honest: it is an early-stage dependency with no meaningful adoption yet, and four items we would eventually need — stock checks, cart events, guest-to-account cart merge, and stale-cart cleanup — are on the maintainer's own unfinished list. Recommendation: adopt for an MVP or internal tool where cart logic is not the differentiator, behind our own thin service wrapper so the package can be replaced without touching feature code. Do not adopt it as the foundation of a high-volume, promotions-heavy storefront without a spike first.

To engineering: The integration surface is small and legible. One interface on Product (CartItemProduct), one config file, one set of migrations, and a Driver contract you can read end to end in minutes. storeItem already increments on duplicate, so every "add to cart" button can hit one code path. Two things to handle deliberately: pin the version against your Laravel release (1.0.1 targets Laravel 13; earlier majors need an earlier tag), and inspect the migration's user_id column type before running it if we use UUIDs. Wrap the facade in our own cart service rather than calling Cart:: from controllers — that gives us one seam to add stock validation, fire our own domain events, and implement guest→user merge on login, all of which the package leaves to us. Treat price returns as strings end to end; do not cast to float in the view layer.