Cart Laravel Package

Technical Evaluation

Vanilo Cart is a domain module within the broader Vanilo e-commerce framework for Laravel. It provides the cart aggregate — cart and cart item models, quantity handling, price resolution, and the adjustment engine used for promotions, taxes, and shipping allocations — exposed through contracts in vanilo/contracts and wired via the Concord module system.

Architecture fit. Fit is high only if the surrounding application is already Laravel and either on Vanilo or willing to adopt its contracts and Concord conventions. The package is not a standalone cart library; it is a bounded context designed to be composed with vanilo/order, vanilo/product, vanilo/pricing, and vanilo/checkout. In a non-Vanilo Laravel app it can technically be installed, but the value proposition degrades quickly because the cart's item resolution, adjuster pipeline, and checkout handoff assume Vanilo's product and pricing abstractions. In a non-Laravel stack, the fit is effectively zero — the implementation is Eloquent-heavy and the public surface is Laravel-idiomatic (service container bindings, facades, migrations, config).

Integration feasibility. Mechanically straightforward for a Laravel engineer: composer install, register the module service provider (Concord auto-discovery or explicit registration), publish and run migrations, bind the cart contracts to Vanilo's default implementations or your own. The adjustment system is the integration point that matters — it is an ordered pipeline of adjusters applied to cart and items, which is where promotions, tax, and shipping logic plug in. Real effort is concentrated in (a) implementing or extending the cart item/product resolution to match your catalog model, (b) deciding whether you adopt the full Vanilo adjuster set or write your own, and (c) the checkout/order conversion path, which lives outside this package and must be sourced from vanilo/order and vanilo/checkout. Expect 1–3 engineer-weeks for a first vertical slice in a Vanilo-shaped app, longer if you are retrofitting contracts.

Technical risk. The dominant risk is ecosystem, not code. Fifty-one stars and zero dependents means essentially no third-party validation, no public integration case studies, and a single-primary-maintainer risk profile typical of the Konekt/Vanilo family. Version churn across the Vanilo 3/4/5 lines has historically included contract and namespace changes, so pinning and upgrade testing are mandatory. Concord adds an indirection layer that new team members must learn before they can debug module loading, migrations, or contract resolution. The cart domain itself is well-trodden and the code follows Laravel conventions, so the implementation risk is moderate; the supply chain and longevity risk is the real concern. There is no evidence of a security review, no CVE history to lean on either way, and support is community/issue-tracker only.

Key questions.

• Are we committing to Vanilo as the commerce substrate, or trying to lift one module out of it? If the latter, what is the exit cost when the next Vanilo major lands?
• Who owns the adjuster pipeline — do we inherit Vanilo's promotion/tax semantics or replace them, and what is the test surface for that?
• What is the checkout-to-order contract we must satisfy, and does it force additional Vanilo modules (order, payment, checkout) into scope?
• What is our upgrade cadence commitment for a package with ~1 maintainer and no dependents signaling production use?
• Do we have a fallback if the package is abandoned — fork, vendor, or replace with darryldecode/cart / gloudemans/shoppingcart plus custom adjustments?

Integration Approach

Stack fit. Assumes PHP 8.x, Laravel 9/10/11 depending on the Vanilo line, Composer 2, and a relational database. Eloquent is non-negotiable; the models are concrete and the contracts assume Eloquent semantics. Queue, cache, and session drivers are configurable but the cart persistence and session binding conventions favor database-backed carts for anything beyond single-session use. If the target stack is Symfony, Rails, or a headless Node front end, this package is out of scope — the correct move is to treat Vanilo's HTTP/checkout layer as the API boundary instead.

Migration path. For a greenfield Vanilo build: adopt the module at project inception, pin the Vanilo minor line, and treat vanilo/contracts as the seam between our domain code and the framework. For an existing Laravel commerce app: do not rip out the incumbent cart. Instead, run a parallel path — stand up Vanilo Cart behind an internal CartService interface, shadow-write from the existing cart, and reconcile totals and adjustment ordering over a release cycle before cutover. For a non-Laravel app: no viable migration path; consider it only as a reference implementation for adjustment ordering.

Compatibility. Watch three axes: (1) Vanilo major line vs. our Laravel version — they move together and are not independently versioned; (2) Concord major version, which gates module discovery and migration behavior; (3) PHP minor. Lock all three in composer.json with caret constraints on the Vanilo line and a committed composer.lock. Avoid dev-main — the project does not have the release discipline or downstream usage to make bleeding edge safe.

Sequencing.

1. Spike (1 sprint): install in a scratch Laravel app, run migrations, create a cart, add items, register one custom adjuster, and drive a cart through to an order via vanilo/order. This single slice surfaces 80% of the integration risk.
2. Contract mapping: enumerate which vanilo/contracts interfaces we implement vs. consume; write adapter tests at each seam.
3. Catalog and pricing alignment: wire item resolution to our product model and confirm price/tax source-of-truth.
4. Adjuster pipeline: define ordering, idempotency, and rounding rules; property-test totals against a reference implementation.
5. Checkout handoff: integrate vanilo/checkout/vanilo/order or build the conversion ourselves with an explicit contract.
6. Production hardening: observability on cart mutation, migration rollback drills, dependency pinning policy.

Operational Impact

Maintenance. Modest code surface but a long dependency tail: Vanilo Cart pulls in vanilo/contracts, vanilo/support, Concord, and typically Eloquent-adjacent helpers. Each upstream release is a potential breaking change with a thin changelog and limited community signal. Budget a recurring maintenance line for quarterly dependency review and one engineer-day per Vanilo minor upgrade, more for majors. Because there are zero dependents, we cannot rely on the ecosystem to surface regressions — our own test suite is the only safety net.

Support. Community-only. GitHub issues, no commercial SLA, no security disclosure process documented in the repo. For a revenue-path component like a cart, that is a real operational exposure: a pricing or tax adjustment bug during peak traffic has no vendor escalation path. Mitigation is a vendor fork under our org with a named internal owner and a documented patch process — this is the single most important operational decision for adoption.

Scaling. The cart itself is not the scaling bottleneck; the adjuster pipeline is. Adjusters run on every cart read or mutation depending on configuration, and a naive promotion set can turn cart totals into an N+1 exercise across items and discounts. Profile adjuster execution under realistic cart sizes (50+ line items, stacked promotions) before launch. Persistence is database-bound, so cart write volume and session affinity matter more than the package. Cart abandonment cleanup needs a scheduled job — Vanilo does not ship opinionated pruning, so we own that.

Failure modes.

• Contract drift on upgrade: module fails to boot or migrations silently no-op. Detect with a smoke test that boots the module and exercises a full cart lifecycle in CI.
• Adjuster ordering bugs: totals shift by cents and only surface at reconciliation. Detect with invariant tests: sum of adjustments + subtotal == total, and idempotent re-application.
• Rounding and currency: mixed-currency or high-precision tax paths are common failure points; assert on stored minor units.
• Abandoned upstream: no commits for two quarters. Detect via a scheduled dependency health check; response is fork-and-maintain per the patch process.
• Module/autoload collisions: Concord registration conflicts with our own service providers. Detect in CI, not in staging.

Ramp-up. A mid-level Laravel engineer is productive on cart CRUD in 2–3 days. The Concord module system, the contracts layer, and the adjuster pipeline are the three learning cliffs — budget 1–2 weeks to first independent feature, and require a written internal runbook covering module boot order, adjuster ordering, and the upgrade procedure. Given the low adoption signal, the ramp-up cost is asymmetric: we are learning an ecosystem we alone will support, so the runbook is not optional documentation, it is the continuity plan.