Laravel Cart Laravel Package

Technical Evaluation

Architecture fit

isapp/laravel-cart is a cart container, not a commerce engine. It gives you persistence, quantity arithmetic, and BCMath-precise totals over a polymorphic itemable relation; it deliberately excludes tax engines, currency handling, discounts, shipping, stock reservation, and events. For a TPM that distinction decides the build-vs-buy call: the package covers roughly the middle third of a checkout domain, and you own the surrounding two-thirds either way.

The shape is good for Laravel. A Cart facade fronts a Driver contract (database or session), the public API is method-chained and small enough to read end-to-end in one sitting, and Cart::extend('custom', ...) plus contract-typed arguments (CartItemContract, CartItemProduct) give you real seams. Because storeItem accepts the contract rather than a concrete class, you can substitute your own CartItem model later — that is the single most important de-risking property in the package, and it should be preserved in any wrapping layer you build.

Best fit: internal tooling, MVPs, B2B order pads, prototypes with a defined checkout path. Poor fit out of the box: consumer storefronts where cart-to-login merge, promotions, or multi-jurisdiction tax matter on day one.

Integration feasibility

Low technical friction, moderate domain friction. Install is one Composer require, two vendor:publish calls, and php artisan migrate. The one non-obvious integration step is making your Product model implement CartItemProduct with exact return types — prices must be numeric strings, not floats — which is where most first-attempt failures will land.

The real effort is in what the README's own ToDo list admits: no guest→user cart merge, no stock validation, no domain events, no expired-session cleanup, no total item/quantity helpers. Merge-on-login alone is a conversion-critical flow you must design and test yourself.

Technical risk

• Community validation is nil. 0 stars, 0 dependents, opportunity score ~35. No CI badge, no test suite referenced, no compatibility matrix. You are an early adopter, not a beneficiary of a crowd-tested package.
• Vendor concentration. Maintained by an agency (ISAPP / ISAP OÜ) whose revenue is client services. Support is best-effort; treat the package as "source available, self-supported."
• Version constraint cliff. Release 1.0.1 pins illuminate/support to ^13. On Laravel 11/12 you must deliberately pin an earlier tag. The absence of a published matrix turns every framework upgrade into a manual investigation.
• Undocumented behavior in the places that hurt: price snapshotting (does a product price change retroactively alter an existing cart?), rounding policy beyond "BCMath, strings", session TTL, and concurrency semantics on increaseQuantity.
• Metadata integrity. The recorded last-release date (2026-10-09) is in the future relative to normal consumption; confirm the actual tag date on Packagist before it enters a dependency register.
• BCMath is a hard runtime dependency and is not mentioned in an installation checklist. Missing extension = fatal on first price calculation.

Key questions

1. Is the item price snapshotted onto cart_items, or resolved live from itemable on every read? This determines whether "price at time of add" can be honored.
2. How does increaseQuantity behave under two concurrent requests? Does the driver use transaction + row lock, or read-modify-write?
3. What is the rounding and scale policy in BCMath? Fixed scale, or caller-controlled?
4. What is the session TTL for guest carts, and where is it configured?
5. Does the database migration hardcode user_id as bigint, and can it be edited safely before first run for UUID/ULID users tables?
6. Are there automated tests in the repository, and what is the coverage of the driver contract?
7. What is the deprecation policy — is Driver treated as stable, or can it grow methods in minor versions (which would break custom drivers)?
8. Who is the accountable maintainer, and what is the response expectation on security issues?

Integration Approach

Stack fit

Requires Laravel with illuminate/support matching the pinned tag, BCMath in the PHP build, and either a relational carts/cart_items schema or a session store. Session-driver deployments on more than one node require a shared session backend (Redis/DB) — otherwise guest carts fragment by node. Add ext-bcmath to the base image and to composer.json platform requirements so it fails at build time rather than at checkout time.

Migration path

Adopt-beside, not adopt-inside. Do not let controllers call Cart:: directly. Introduce one port — App\Cart\CartService — that wraps the facade and exposes only the operations your product needs (add, set quantity, remove, totals, merge). Behind it, the package is one implementation. That wrapper is the entire exit strategy: the package's own API is small enough that a replacement is a sprint, not a quarter, and the wrapper bounds the blast radius of abandonment.

Alongside it, publish and edit before running: adjust user_id column type to match your users table, add an index on session_id, and add a created_at/updated_at-driven TTL column if you want cleanup to be index-friendly.

Compatibility

Pin the exact version in composer.json and lockfile; never float. Record the resolved version and its Laravel constraint in the dependency register. If the team is on L11/L12, identify and pin the last compatible tag explicitly and note that it will not receive fixes. Gate framework upgrades on a documented spike of this package.

Sequencing

1. Day 1–2 — Spike. Scratch Laravel app on the target framework version. Read Contracts/Driver, Contracts/CartItemProduct, and the published migrations. Exercise guest add, authenticated add, quantity up/down, and totals. Verify BCMath is present.
2. Day 3 — Behavior probes. Write throwaway tests for price change after add, two parallel adds, and a guest→login transition. The answers determine the size of everything downstream.
3. Decision gate. Compare "adopt + build missing 60%" against "build the container in-house" — honestly, the container is ~500 lines. Adopt only if the spike confirms snapshotting and concurrency are acceptable, or if speed to first demo dominates.
4. Foundation. Migrations edited and dry-run on a staging snapshot; CartService port in place; feature flag or separate route prefix so the cart can be disabled without a revert.
5. Domain layer. Stock validation before storeItem; login listener performing guest→user merge then emptying the session cart; observability hooks at the service boundary (since the package fires no events) for add-to-cart funnels.
6. Lifecycle. Scheduled cleanup command with a configured TTL, running before the carts table becomes a growth problem.

Operational Impact

Maintenance

Low code churn, moderate ownership burden. The package is unlikely to move fast, which is stabilizing, but it also means the ToDo items (merge, events, stock validation) will not arrive from upstream on your schedule — budget them as your code, permanently. Custom drivers are the main maintenance trap: if Driver gains methods in a minor release, every Cart::extend implementation breaks at runtime. Keep custom-driver use to zero unless you need it.

Support

No SLA, no security disclosure process documented, no issue-triage history to benchmark against. Assume self-support. The README is genuinely good — full API listing with examples and error handling — which reduces onboarding cost and makes source reading cheap. Budget one engineer as the named owner and treat upstream PRs as optional.

Scaling

Cart row counts grow monotonically per user/session; without cleanup, cart_items becomes the largest low-value table in the schema within a year. Add the cleanup job in the first release, not later. Per-request cost is one to two queries for the DB driver — negligible against typical page weight, and eager loading is claimed for item reads. Price totals are computed in PHP over the item collection with BCMath; fine at normal cart sizes (tens of items), worth a benchmark if you support bulk/B2B carts in the hundreds. Session driver scales with your session store, not with the package.

Failure modes

Ramp-up

A mid-level Laravel engineer reaches productive use in two to four days: the API surface is small, the README covers every method with examples, and storeItem incrementing on duplicate removes a common branch. The cost is not learning the package — it's learning the unwritten behavior (rounding, TTL, concurrency, snapshotting), which is exactly what the spike is for. Do not let a second engineer discover those empirically in production.