- What is sylius/cart and what does it do?
- sylius/cart is a read-only PHP cart library that provides reusable domain components for shopping cart functionality. It includes cart and cart item models, cart operations, item collection management, and integration points for pricing, promotions, and checkout in Sylius-based e-commerce applications. It is not a Laravel-native package and should be evaluated as a PHP domain library.
- Is sylius/cart compatible with Laravel?
- It is not a drop-in Laravel package. The library is designed around Sylius, Symfony, and Doctrine conventions, while Laravel uses Eloquent, its own container, events, validation, and session lifecycle. The cart domain concepts may be reusable, but expect to build adapters and run a compatibility spike before committing.
- Can I install sylius/cart in a Laravel app with Composer?
- Composer installation may be technically possible, but practical feasibility depends on transitive dependencies and PHP/Laravel version compatibility. Because the package is archived and read-only, any incompatibility must be fixed by your team through a fork or local patch. Audit the lockfile for Symfony, Doctrine, and Laravel conflicts before starting implementation.
- Which Laravel and PHP versions does sylius/cart support?
- The provided context does not specify supported Laravel or PHP versions, so you must confirm this through a dependency audit. Archived packages often lag current PHP and Laravel releases, and upstream fixes should not be expected. Test against your exact target runtime and framework version in a short-lived branch.
- Does sylius/cart require Symfony or Doctrine?
- The package is most likely designed around Symfony and Doctrine conventions and may have hidden coupling to Sylius resource, order, currency, and pricing components. The exact dependency graph must be verified from Composer metadata and source inspection. For Laravel, plan for repository, container, and event adapters rather than direct Eloquent integration.
- Is sylius/cart actively maintained?
- No, sylius/cart is archived and read-only, with only about 15 stars and a very low assessment score. The MIT license allows forking, but it does not provide maintenance, security patching, or Laravel compatibility work. Your team would own bug fixes, dependency upgrades, and PHP/Laravel compatibility if you adopt it.
- What are the production risks of using sylius/cart in Laravel?
- The main risks are dependency resolution failures on Laravel or PHP upgrades, Symfony/Doctrine coupling that resists Laravel integration, and cart total or price drift from mismatched pricing and promotion rules. Stale dependencies may also create runtime or performance risk under high traffic. Isolate the library behind interfaces and add regression and load tests before production use.
- What alternatives to sylius/cart should I consider for Laravel?
- Consider a maintained Laravel-native cart package or building the cart bounded context internally with Eloquent and Laravel events. If your application already runs a Sylius or Symfony stack, sylius/cart may fit better inside that environment. Compare the cost of adapting an archived library against the cost of owning a small Laravel-native cart implementation.
- How should I test or spike sylius/cart before adopting it?
- Run a time-boxed technical spike: install it in a branch, resolve dependencies, map core models to Laravel persistence through repositories, wrap services in Laravel's container, and translate domain events. If the spike exposes hard dependency conflicts or requires extensive forking, stop and choose a maintained alternative. Gate full implementation until viability is proven.
- Can I use only sylius/cart domain models and keep Laravel as the framework?
- Yes, but treat it only as an isolated domain library behind interfaces and adapters, not as a direct controller or Eloquent dependency. You will still need to implement persistence, container wiring, event translation, and integration with pricing, tax, shipping, promotion, inventory, and checkout handoff. This approach reduces coupling but does not remove the maintenance burden of an archived package.