Weave Code
Cart Manager Laravel Package
freshbitsweb/cart-manager
Freshbitsweb Cart Manager is a lightweight Laravel package for e-commerce carts. It manages items, quantities, prices, totals, taxes, discounts, and multiple cart instances through a clean, fluent API, making it easy to add robust cart functionality to any Laravel application.
Managing the cart in your Laravel/E-commerce application is a breeze
Frequently asked questions about Cart Manager
- How do I install freshbitsweb/cart-manager in a Laravel application?
- Install it with Composer by running composer require freshbitsweb/cart-manager, then publish the package configuration with php artisan vendor:publish so your overrides live in your own repo. The service provider and facade are auto-discovered, so you can resolve the cart manager from the container or facade right away. If you choose the database driver, run the package migrations to create the cart tables. A basic add-to-cart, totals, and persist flow is typically an afternoon of work for a Laravel developer.
- Does freshbitsweb/cart-manager support Laravel 11 and Laravel 12?
- That is not proven. The last published release is dated 2023-02-28, which predates Laravel 11 and 12, so treat compatibility as an open question rather than an assumption. Run composer why-not freshbitsweb/cart-manager to see what your installed Laravel and PHP versions block before committing to the package. Laravel 8 and 9 are the safest bet, and on Laravel 10 or newer you should gate your spike on a verified install.
- How do multiple cart instances work for guests and logged-in users?
- Every cart is keyed by an identifier you supply, such as a session ID, user ID, or tenant ID, so one application can hold many independent carts at once. That maps cleanly onto the common pattern of a guest cart keyed by session and an authenticated cart keyed by user ID. You own the mapping and lifecycle of those identifiers, which is exactly where the guest-to-user merge decision lives.
- Should I use the session cart driver or the database cart driver?
- The session driver is simplest and fine for short-lived guest carts, while the database driver persists carts across devices and sessions and ships with migrations. Pick the database driver if you need abandoned-cart reporting, cross-device continuity, or carts that survive session expiry. Note that item custom attributes are typically stored in a JSON column, so anything you need to validate or report on downstream should get an explicit column or an internal DTO. You also inherit cleanup responsibilities such as pruning abandoned carts and adding sensible indexes.
- Does the package calculate taxes and discounts automatically?
- No. Expect the ability to apply a tax amount or discount amount to a line item or to totals, not a promotion rules engine, coupon stacking, or jurisdiction-aware tax calculation. The package is best treated as a cart state container for items, quantities, prices, attributes, and totals, with tax and pricing policy remaining a first-class decision you own. If you sell cross-border, budget for integrating a dedicated service such as Stripe Tax, TaxJar, or Avalara rather than relying on in-package arithmetic.
- Are cart prices and totals stored as floats or integer minor units?
- Confirm this in the source or a quick spike before you build on top of the package, because float money is the most expensive class of bug to retrofit later. If prices are floats, normalize to integer minor units at your adapter boundary, or accept and explicitly document the rounding drift. Either way, keep a single conversion point so your order and invoice layers never see mixed representations.
- How do I merge a guest cart into the user's cart after login?
- Session carts and user carts are different rows, so merging is your code and your product decision, not a package default. Decide explicitly whether to combine quantities, keep the latest price, or prompt on conflicts, then write the merge at the authentication boundary and test it thoroughly. Doing this inside a login listener keeps the logic in one place and stops duplicate carts from accumulating.
- How should I test cart behavior in my Laravel test suite?
- Because the cart is stateful, test at the boundary: add items, change quantities, apply amounts, and assert totals using the session driver with array sessions or a database driver with RefreshDatabase. Check whether the package fires events on mutation; if it does, assert them, since they are what feeds abandonment analytics and audit trails. Keep a small set of feature tests around guest-to-user merge and idempotent order creation, which are the paths that actually break in production.
- Is freshbitsweb/cart-manager actively maintained?
- The most recent published release is from February 2023, so any earlier claim of active maintenance should be re-verified against the tag history. Read the release notes; a release without usable notes is a gating signal, and until that is resolved pin exact versions in composer.json. Plan a fork contingency rather than being surprised, and check whether the maintainer has stated a version-support policy or a succession plan.
- What are the alternatives, and when should I not use this package?
- Consider it when you want a lightweight, Laravel-idiomatic cart state container with multiple named instances; look at something heavier if you need built-in promotion rules, coupon stacking, or jurisdiction-aware tax. Avoid it if checkout runs in a separate non-Laravel service, because the package's persistence model would quietly become your de facto cart API contract. It is also a poor fit for teams that cannot fork and maintain a dependency whose release cadence has stalled. In those cases a small bespoke cart table plus your own DTOs is often cheaper than adopting and then escaping a package.
Weaver
How can I help you explore Laravel packages today?