Cart Bundle Laravel Package

Technical Evaluation

Architecture fit

• sylius/cart-bundle is a Symfony bundle, not a Laravel package. It presumes Symfony's DI container, EventDispatcher, Doctrine ORM, Form component, and Sylius core abstractions (Order/OrderItem, state machine, processor pipeline). Laravel has no bundle system, and its container, Eloquent, HTTP kernel, and Blade stack provide no mapping to those extension points.
• The cart domain it models — Cart, CartItem, a session-backed CartProvider, ItemResolver implementations, and a configurable totals-processor pipeline — is separable and portable as a design, not as code.
• Treat it as a reference architecture for a cart bounded context. It is not a candidate dependency for a Laravel application.

Integration feasibility

• Low. The repository is archived and its own description redirects to Sylius/Sylius; the functionality now lives in Sylius\Component\Order. Composer may still resolve it, but there is no maintained release line, no security process, and zero dependents — no community validation to lean on.
• Real consumption would require either embedding a Symfony runtime beside Laravel or replacing Laravel's commerce layer with Sylius. Both are architectural commitments, not integrations.
• The only cheap integration is the one we should take: reading the source to extract schema, resolver, and pipeline patterns.

Technical risk

• High and unmitigated. No security patches, no PHP/framework compatibility guarantees, and a heavy transitive dependency graph (Doctrine, Symfony components) that will contend with Illuminate's shared Symfony constraints.
• Sylius's order model is materially richer than a typical Laravel cart — promotions, adjustments, state machines — which adds schema and recalculation cost disproportionate to a straightforward cart requirement.
• Abandoned status is a governance flag: any defect we encounter becomes ours to own, permanently, with no upstream recourse.

Key questions

• Is there an existing Sylius/Symfony service we must interoperate with, or is this an attempt to reuse code inside a pure Laravel app? The answer changes everything downstream.
• What cart semantics are actually required — guest carts, merge-on-login, tax, promotions, multi-currency, per-unit line splitting?
• Are we willing to fork and own maintenance, including security review of transitive dependencies?
• What Laravel-native or headless-cart options have already been evaluated and rejected, and on what criteria?
• What is our standing policy for archived packages in the dependency tree, and does this trigger a remediation item?

Integration Approach

Stack fit

• Poor. A Symfony bundle is a foreign-framework artifact in a Laravel codebase. Laravel-native cart packages or a custom Eloquent-backed domain fit the stack; this does not.
• If Sylius is strategically required, the only defensible shape is Sylius as a separate Symfony service behind an HTTP API, with Laravel as an API client — never as vendored code inside the app.

Migration path

• Do not vendor the bundle. Port the domain concepts instead: Cart/CartItem models, a cart provider bound as a scoped singleton, cart item resolvers that normalize user input into a line, and a cart-operation pipeline expressed via Laravel Pipeline and events.
• Start from schema, not from a package: integer minor units for price (never floats), a morphs buyable relation, a uniqueness constraint on (cart_id, buyable_type, buyable_id), and session/user keys indexed for cart resolution.
• If Sylius already exists in the estate, upgrade to the Sylius/Sylius monorepo and expose the Shop API rather than pinning the legacy bundle.
• Map Doctrine XML mappings to Eloquent models and Symfony event subscribers to Laravel listeners/jobs. This is a rewrite, not an adapter.

Compatibility

• Symfony 2/4/5-era component constraints will collide with Laravel 10/11's shared Symfony components; expect Composer conflict resolution work and likely a hard stop.
• No service provider, no config publishing, no facade, no artisan surface. Every integration point is manual.
• Doctrine-to-Eloquent persistence is a full abstraction mismatch, not an adapter away.

Sequencing

1. Timeboxed spike (1–2 days) to document incompatibility and dependency conflicts — useful evidence for the decision record.
2. Requirements workshop on cart semantics, guest handling, and scale targets.
3. Structured evaluation: Laravel-native package vs. in-house build vs. Sylius-as-a-service.
4. If Sylius is chosen, stand up the service, define and version the API contract, then integrate.
5. Load-test cart writes and merge-on-login races; add contract tests.
6. Record the archived-package decision and an explicit exit/deprecation path in the architecture log.

Operational Impact

Maintenance

• Archived means we own any fork in full. No upstream fixes, no security backports, no compatibility work. The ongoing cost is high relative to the modest value of a cart module, and it accrues quietly until an upgrade forces the issue.

Support

• No maintainer support and no support pathway. Available community knowledge is Sylius-centric and assumes Symfony fluency, which our team does not have. Internal ramp-up documentation would need to be authored and maintained by us.

Scaling

• The bundle is not the bottleneck; cart storage is. Session-backed carts break under horizontal scaling — plan Redis or database persistence with a clear eviction policy.
• Cart writes are contention-prone: concurrent tabs, merge-on-login, and re-price-on-mutation all serialize on the same cart row. Sylius's adjustment recalculation per mutation amplifies that cost.

Failure modes

• Routine PHP/Laravel upgrades breaking CI through transitive dependency conflicts.
• Transitive-dependency CVEs with no patch path and no upstream to notify.
• Order/cart state-machine inconsistency after partial failures during conversion.
• Silent cart data loss from session expiry or merge races.
• Security or dependency audits blocking a release with no remediation available except removal.

Ramp-up

• Days-to-weeks for a Laravel team to become productive with Symfony DI, Doctrine, and the Sylius state machine — effort spent on framework translation rather than product value.
• The same team reaches a working Laravel cart in roughly a week from the extracted patterns. The reference material is the deliverable; the dependency is not.
• Recommendation: use this repository as a design input, exclude it from procurement and dependency decisions, and inventory any existing usage as a scheduled migration item.