Cart Laravel Package

Product Decisions This Supports

• Build vs. buy for cart and checkout foundations. sylius/cart is a domain-model component, not a turnkey cart. It gives you the shape of a cart (cart, cart line items, item units, quantity/state modeling) but not a cart experience. Its real product value is as a reference architecture when you are deciding whether to hand-roll cart logic or buy into an established commerce domain model.
• Platform selection: Sylius-as-a-platform vs. Sylius-as-parts. This package is one node in the Sylius component graph. Evaluating it forces the more important decision — do we adopt Sylius wholesale (full stack, bundles, admin, checkout) or attempt to cherry-pick components into a bespoke application? The second path is where teams get hurt, and this package is the cheapest possible way to discover that before committing a quarter of engineering time.
• Roadmap sequencing for a first commerce launch. If a near-term milestone is "sell something," the honest read is that this package saves you zero weeks over a mature off-the-shelf platform and negative weeks over a modern hosted cart/checkout. It supports a deferral decision: don't let cart modeling block the launch critical path.
• Architecture posture: monolith vs. composable. The component presumes Symfony, Doctrine, and the Sylius Order component underneath it. That is a strong signal about which architecture you are actually choosing. Useful input to a "composable commerce" strategy debate — composability here means "assemble many first-party components," not "assemble independent vendors."
• Reuse of a proven order/cart state model outside ecommerce. The cart-as-order pattern (a cart is an order in an early state, with transitions) is genuinely transferable to procurement baskets, quote-to-cash drafts, subscription boxes, and internal requisition flows. Reviewing this package is a legitimate way to shortlist a state-machine-driven domain model for those use cases.
• Dependency and maintenance risk register. This is an archived, read-only mirror. It is a concrete, checkable line item in any vendor-risk or OSS-governance review, and it should be used to pressure-test how the team evaluates every dependency, not just this one.

When to Consider This Package

Consider reading it (not installing it) when:

• You are already committed to Sylius or the Sylius component family, and you want to understand the cart/order contract before customizing it. In that world you get this code anyway, via sylius/sylius — see the caveat below.
• You need a domain modeling reference — how to represent line items, item units, quantity changes, and cart-to-order state transitions — and you want a known-deployed example rather than a blog post.
• You are sizing a build vs. buy analysis and need a concrete floor for "what does a from-scratch cart model actually look like."
• Your team is Symfony-native and you are deliberately assembling a bespoke commerce stack from first-party components, accepting the integration cost as a strategic bet.

Look elsewhere — or stop — when:

• You intend to composer require it as a live dependency for new work. It is archived. Archived means no bug fixes, no security patches, no PHP-version compatibility work, no maintenance of transitive constraints. A cart is on the payment path; unmaintained code on the payment path is an unacceptable risk position for a PM to sign off on.
• You are not on Sylius. The cart component is deeply entangled with the Order component, currency/pricing, and Doctrine mappings. Adopting it standalone means adopting a meaningful slice of the Sylius object graph — a build-vs-buy decision disguised as a small library install.
• You need a cart feature, not a cart model. There are no controllers, no routes, no persistence workflow, no API surface here. Everything a shopper touches is yours to build.
• You measure dependency health by stars, release cadence, or support. 15 stars and "archived" is accurate but misleading in both directions: the parent Sylius project is substantial and battle-tested, while this specific artifact is frozen. Do not read either signal alone.
• You need modern PHP or current framework support guarantees. Frozen code has a compatibility ceiling that will eventually collide with your upgrade cycle — usually at the worst possible moment.

The correct move for most teams: evaluate the parent project (sylius/sylius), or evaluate a maintained commerce platform, and treat sylius/cart as documentation. If you conclude you want this domain model, pull it through the maintained monorepo, not this mirror.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, well-designed piece of ecommerce plumbing from a credible open-source commerce project — but the specific package is archived, meaning nobody is fixing bugs or security issues in it. We should not put it on the payment path of a revenue-generating product. It is genuinely useful as a reference for how to model a shopping cart, and as a cheap way to stress-test our build-vs-buy thinking before we commit engineering time. Recommendation: use it to inform the decision, not to make it; the real decision in front of us is "adopt Sylius as a platform" or "buy a maintained cart/checkout," and this package helps us frame that choice at near-zero cost.

For engineering (the operative summary):

• What it is: the cart domain model from Sylius — cart, cart item, item unit, quantity and state-transition semantics, Doctrine mappings. Symfony- and Doctrine-coupled; depends on the Order component and its object graph. Model only; no controllers, routes, or API.
• Status: read-only mirror of a monorepo, now archived. Do not add as a dependency. Development, if any, happens upstream in sylius/sylius.
• Recommended use: read it to calibrate our own cart/order model, or to validate integration cost estimates if we pursue a component-assembly strategy.
• Recommended path if we want this model in production: adopt sylius/sylius (maintained, documented, supported) rather than the split package — and only if the broader Sylius platform bet is one we want to make.
• Explicit non-goal: do not fork and self-maintain it as a "cheap" middle path. That converts a free dependency into a permanent, undocumented internal platform with a single point of failure.
• Ask: one spike, timeboxed, to compare (a) Sylius platform, (b) maintained hosted cart/checkout, (c) bespoke build — with this model as the yardstick for (c). Decision to follow.