Weave Code
Sales Bundle Laravel Package
sylius/sales-bundle
Sylius Sales Bundle provides the core sales order model and processing logic for the Sylius e-commerce platform, including orders, order items, adjustments, and order state handling—a foundational component for building flexible online stores and custom checkout workflows.
[READ-ONLY] Orders engine for Symfony2 e-commerce solutions.
Frequently asked questions about Sales Bundle
- Can I install sylius/sales-bundle in a Laravel application?
- No. It is a Symfony 2.x bundle that depends on Symfony's service container, bundle bootstrapping, Doctrine annotations, and the Symfony event dispatcher, so Composer will not resolve it into a modern Laravel install. Treat it as a domain design reference rather than a runtime dependency.
- Is sylius/sales-bundle compatible with Laravel 10 or Laravel 11?
- It is not compatible. The package targets the Symfony 2 era and is archived read-only, with no commitment to current PHP, Doctrine, or Symfony versions. Modern Laravel requires PHP versions and dependency constraints that this bundle does not satisfy.
- What does sylius/sales-bundle actually provide?
- It defines reusable Order, OrderItem, and Adjustment entities with Doctrine ORM mappings, plus order state machine support for checkout and fulfillment. Entities are configurable through the Sylius resource system and designed to be extended or overridden. It also integrates with other Sylius bundles for payments and shipping.
- Is sylius/sales-bundle still maintained?
- No. The repository is archived and read-only, with roughly 18 stars and zero dependents, which means there is no security patching, no compatibility work, and no one to escalate issues to. Adopting it creates an immediate fork liability.
- What is the best way to use sylius/sales-bundle ideas in Laravel?
- Extract the domain model instead of the code. Reimplement the orders to order_items to order_item_units shape, a polymorphic adjustments table, derived totals rather than a mutable total column, and an explicit order state machine using Eloquent, Laravel domain events, and a workflow package such as spatie/laravel-model-states or symfony/workflow.
- How does the Sylius order state machine translate to a Laravel workflow?
- The Sylius lifecycle runs cart, addressed, shipping_selected, payment_selected, confirmed, then fulfilled or cancelled, and that sequence is framework-agnostic. In Laravel you can model it with symfony/workflow used standalone or spatie/laravel-model-states, firing Laravel domain events on each transition.
- Are there maintained alternatives to sylius/sales-bundle for Laravel?
- Yes. Evaluate current Sylius if you need the full Symfony commerce stack, a maintained Laravel commerce package if you want a ready-made storefront, or plain Eloquent plus symfony/workflow if you only need the order aggregate and state machine. The archived Sylius SalesBundle should not be on that list as a dependency.
- What are the production risks of depending on sylius/sales-bundle?
- The upstream is abandoned, Symfony 2 is end-of-life, and there is no security patching or compatibility commitment with current PHP. You would own a permanent fork with no escalation path, which is a high and asymmetric operational risk.
- Does sylius/sales-bundle work with Eloquent or only Doctrine?
- Only Doctrine. The bundle ships Doctrine ORM annotations and superclass mappings for its entities, while Laravel's default persistence is Eloquent. Bridging the two would require a custom shim with no upstream support, so reimplementing the entities as Eloquent models is the realistic path.
- How do I migrate legacy Sylius order data into a Laravel application?
- Do a one-time ETL from the legacy Symfony 2 database into your new Eloquent schema, mapping orders, order items, order item units, and adjustments explicitly. Never carry the bundle forward as a runtime bridge, because that permanently ties your Laravel application to archived Symfony 2 code.
Weaver
How can I help you explore Laravel packages today?