Cart Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for the cart domain. sylius/cart-bundle is a useful specification of what a cart bounded context owns: cart and cart-item persistence, add/remove/update line items, a recalculation pipeline for totals, a current-cart provider, extensible item resolvers, and the cart-to-order handoff. That decomposition is directly reusable as the acceptance-criteria skeleton for a Laravel-native build or a vendor evaluation rubric — regardless of whether you ever touch the code.
• Platform selection, surfaced as a package decision. The repo redirects to Sylius/Sylius; the real question it raises is "do we adopt Sylius as a platform" versus "do we implement cart in Laravel." Treat the dependency as a pointer to that strategic conversation, not a candidate in the backlog.
• Requirements pressure-testing. Four behaviors this bundle implicitly validates: guest carts, cart merge on authentication, totals recalculation on quantity change, and cart/order separation. If your PRD doesn't state a position on each, your spec has a gap — and this bundle is a cheap way to find it.
• Legacy modernization roadmap. Any usage of this bundle in the estate is a migration work item, not a feature. It signals an end-of-life dependency that will eventually block a PHP/framework upgrade path and should be scheduled with an exit owner.
• Deprecation-governance precedent. With 0 dependents and an archived status, it's a concrete example for a dependency policy: archived packages are blocked from new adoption and inventoried in existing code. Use it to justify the policy rather than debate it case by case.
• What it should not support: procurement, dependency addition, or a "reuse existing OSS" narrative. Its only positive product decision is reference modeling.

When to Consider This Package

Consider it in exactly two narrow cases:

1. Read-only reference during design. You're scoping or designing a cart domain and want a battle-tested example of entity relationships, line-item resolution, recalculation pipelines, and cart-to-order state transitions. Read the code; do not require it.
2. You already own a legacy Symfony application pinned to it. Then the action is understanding-before-migration, and the target is the Sylius monorepo or an in-house replacement — not continued investment.

Look elsewhere — decisively — when:

• Greenfield or any new build. Archived and deprecated means no security patches, no compatibility work, no maintainer to escalate to. That's supply-chain risk, not a shortcut.
• You're on Laravel. This is a Symfony bundle: it assumes Symfony's DI container, EventDispatcher, Doctrine ORM, Twig, and Sylius core abstractions. Bridging it means embedding a Symfony runtime or rewriting Doctrine entities as Eloquent models — a full rewrite wearing an adapter's clothes.
• You need support, SLAs, or a patch path. None exists. Any defect you hit becomes yours to fix, including transitive-dependency CVEs.
• Cart is core to your differentiation. Then own it: a small Eloquent-backed domain (carts, cart_items, a CartManager singleton, an item resolver, an operation pipeline) delivers ~90% of this bundle's value in days.
• You want a drop-in maintained cart. Evaluate a maintained Laravel cart package, or if Sylius is strategically required, run it as a separate Symfony service behind an HTTP API and integrate Laravel as an API client.
• Modern PHP/runtime compatibility is required. Archived projects drift out of step with current PHP versions quickly; assume incompatibility rather than graceful degradation.

How to Pitch It (Stakeholders)

To executives: This package is archived, marked deprecated, and its own maintainers point elsewhere. It is not a viable dependency: no security patches, no support path, and an upgrade liability that grows every PHP release. Recommendation: exclude it from build-or-buy evaluations and treat it strictly as a design reference. If it appears anywhere in our codebase or vendor tree, log it as a remediation item with a named owner and a scheduled exit date — prioritized by whether the affected service sits on an active upgrade path.

To engineering: Treat sylius/cart-bundle as documentation, not a dependency. Its value is as a reference model for the parts of cart we tend to under-specify: cart/order separation, cart-item resolution as a single normalization seam, a recalculation pipeline for totals, guest-cart merge on login, and the state transitions into order. Do not add it to a Laravel application — it is Symfony-native and would drag in DI, eventing, and Doctrine conventions for a component that is cheaper to own. Port the concepts: carts / cart_items schema with integer minor-unit prices, a scoped CartManager resolving cart from session or auth, an item resolver that converts user input into a validated line, and a pipeline for totals. Money in integers, never floats; cart storage in Redis or the database, never the session, if we expect to scale horizontally.

Bottom line: the only defensible decision this package supports is not to adopt it. Use it to sharpen the cart requirements and to confirm the cart is a separable bounded context — then build it natively in Laravel or buy something maintained and supported.