Cart Bundle Laravel Package

Technical Evaluation

Architecture fit — a Symfony 2 bundle, not a Laravel package; relevant only as a domain blueprint. Despite being catalogued as a Laravel/PHP package, Leaphly CartBundle is a Symfony full-stack bundle. It registers services via DependencyInjection/*Extension and compiler passes, hooks HttpKernel events, and exposes HTTP via FOSRestBundle + JMSSerializer + Twig. Laravel has no bundle system, no compiler passes, no HttpKernel. There is no conventional path to composer require and boot this in a Laravel app.

What is directly useful is the domain architecture: a cart aggregate (cart → cart item → product/variant reference), a guarded state machine (cart → wishlist → ordered), pluggable price/item resolvers, and event dispatch on cart mutation. Those concepts translate cleanly to Laravel idioms (Eloquent, spatie/laravel-model-states or a transition table, pipeline calculators, Laravel events). The realistic fit, from a TPM framing, is reference material for a build decision, not a dependency.

Integration feasibility — low for adoption, moderate for extraction.

• Runtime dependencies are Doctrine ORM + Doctrine\Common\Collections, Symfony EventDispatcher/Form/Validator/OptionsResolver, and FOSRestBundle/JMSSerializer/Twig. None of these integrate into a Laravel request lifecycle without a compatibility shim.
• The shim path (booting a second Symfony kernel inside Laravel) is technically possible and operationally an anti-pattern: two containers, two event systems, duplicated config, unclear transaction boundaries between Eloquent and Doctrine.
• The extraction path (read models, state machine, resolver contracts; reimplement natively) is 1–3 weeks of engineering and produces code you own outright.

Technical risk — high, dominated by abandonment.

• Zero dependents and 101 stars is a strong abandonment signal. The Symfony 2 era it targets reached EOL years ago. Assume no upstream fixes, no security patches, no PHP 8.x or Laravel 10/11 support.
• Expect hard composer conflicts on the first install attempt against a modern Laravel lockfile.
• Unverified items to confirm in a spike: exact composer.json PHP/Symfony constraints, CI status, test coverage, license, and whether any fork has modernized it.
• Zero dependents means no field testing outside the original authors — pricing and state-transition edge cases are yours to discover.

Key questions for the team

1. What problem are we actually solving — persistent cart storage, pricing/promotion calculation, or order-state workflow? The bundle is genuinely strong only on the third.
2. Do we need multi-currency, tax, and promotion stacking on day one? Its calculators are simple and would be replaced regardless.
3. Who owns the code after integration? If "nobody," the build-vs-adopt math already favors build.
4. Is the cart a system of record or an ephemeral session artifact? That drives the entire persistence and scaling design.
5. What is the cost of a 2–3 week native build versus indefinitely forking an EOL Symfony bundle?

Recommendation: Do not adopt as a runtime dependency. Fund a short extraction spike and treat the bundle as an architectural reference.

Integration Approach

Stack fit — none at runtime. A modern Laravel stack (PHP 8.x, Laravel 10/11, Eloquent, Illuminate events/queues) is structurally incompatible with a Symfony 2 bundle pinned to PHP 5.x-era constraints and Doctrine 2.x-era APIs. There is no supported version matrix where both coexist cleanly.

Migration path — harvest, don't port.

1. Spike (3–5 days): vendor the repo read-only; document the cart state machine, item model, and price resolution contract from source and tests.
2. Domain design (2–3 days): map to Laravel — carts, cart_items, cart_item_variants tables; a state column with explicit transition guards; a CartCalculator pipeline for line price, tax, discounts; domain events (CartItemAdded, CartStateChanged).
3. API surface: Laravel API Resources + Form Requests replacing FOSRestBundle/JMSSerializer; policies for cart ownership.
4. Concurrency: optimistic locking (version/updated_at guard) on cart writes — the bundle's guard logic does not address concurrent session writes.

Compatibility — blocking for direct adoption. Expect composer conflicts on doctrine/orm, symfony/*, jms/serializer, and friendsofsymfony/rest-bundle. Even if resolved in isolation, PHP constraints typically exclude modern runtimes. Verify composer.json first; a php: >=5.3,<5.5-style constraint closes the direct-adoption path in minutes.

Sequencing

• Week 0: feasibility probe (composer why-not in a scratch branch) — a two-hour test that validates or kills direct adoption.
• Week 1: extraction spike + domain write-up as the deliverable.
• Weeks 2–4: native cart behind a feature flag, shadow-mode against any existing cart logic.
• Week 5: cutover with a rollback flag; keep the old path for one release cycle.

Do not run dual carts in production — two systems of record for the same user session is a defect generator.

Operational Impact

Maintenance — the dominant cost. Upstream is effectively frozen. Adopting means forking, owning, and patching: PHP upgrades, dependency bumps, security backports — a permanent tax versus owning ~2,000 lines of Laravel-native code. The zero-dependents signal also means no external bug reports to free-ride on.

Support — none. No vendor, no active maintainers, no Laravel community around it (there is no Laravel use case). Internal documentation is written from scratch. The escalation path is "the person who read the source."

Scaling — addressed by the reimplementation, not the package. Cart workloads are write-heavy and spiky (add/remove/quantity churn), and the bundle's persistence is straightforward relational writes. A native build should keep carts in Redis/Postgres with a TTL, persist durably on checkout intent, and index on user_id/session_id. Running the bundle would introduce a second ORM/connection pool to tune and monitor for no benefit.

Failure modes to plan for

• Price calculation drift — silent mismatch between cart totals and checkout totals if calculators are ported incompletely. Mitigate with golden-file tests over a fixture corpus of carts.
• State machine races — double-submit converting a cart to "ordered" twice. Mitigate with DB-level unique constraints and idempotency keys on the transition endpoint.
• Orphaned cart items — deleted products leaving dangling references. Mitigate with soft deletes and a resolver that returns an "unavailable" line rather than throwing.
• Serialization/compat breaks — if legacy payloads exist, require an explicit adapter and migration script.
• Dependency rot — if direct adoption is attempted anyway, the first composer update six months in becomes multi-day archaeology.

Ramp-up A team unfamiliar with Symfony 2 idioms (compiler passes, services.yml, annotation routing, Doctrine UnitOfWork) needs ~1–2 weeks just to read the source productively — and that investment yields a design document, not shippable code. A Laravel-native cart is ~2–3 weeks for a mid-level engineer with existing Eloquent experience: comparable effort, materially better outcome and ownership. The ramp-up only pays off if the bundle is treated as documentation, which is the recommended posture.