Core Bundle Laravel Package

Getting Started

sylius/core-bundle is not a Laravel package — it's the Symfony bundle that wires Sylius' core domain (Order, Product, ProductVariant, Customer, Channel, Promotion, Payment, Shipment, TaxRate, Zone) plus its resource registry, state machines, Doctrine XML mappings, and fixtures. There is no config/app.php provider registration, no Eloquent models, no facade. If your day job is Laravel, the honest first step is to confirm whether you're actually adopting Sylius as a platform; if not, close the tab.

If you are adopting it, the install is transitive, not direct. Require the platform, not the split:

composer require sylius/sylius-standard   # or sylius/sylius for headless

Never pin sylius/core-bundle independently — it's a read-only subtree split of the Sylius/Sylius monorepo and its versions are locked to the parent release train. Pull every sylius/* constraint from one place (the platform's composer.json) and let Composer resolve the rest.

Look first at, in order:

1. src/Kernel.php — it extends Sylius\Bundle\CoreBundle\Application\Kernel, which registers every component and admin/shop/API kernel. The bundle list there is your map of what the platform actually installs.
2. config/packages/_sylius.yaml + config/packages/sylius_*.yaml — resource overrides (sylius_product.resources.product.classes.model), state machine overrides, grid config.
3. Sylius\Component\Core\Model\* — the domain interfaces. Read OrderInterface and ProductVariantInterface first; everything else hangs off them.
4. vendor/sylius/core-bundle/Resources/config/ — Doctrine XML mappings and service definitions. This is where you learn what a "resource" actually is.

A sensible first use case: override the Product model to add a custom field and wire it through the resource, form, and grid layers — this exercises resource override, Doctrine mapping extension, form type extension, and grid config in one pass, which is 80% of day-to-day Sylius work.

Implementation Patterns

Resource overrides, not model edits. Sylius is built around a resource registry. The day-to-day pattern is:

# config/packages/_sylius.yaml
sylius_product:
    resources:
        product:
            classes:
                model: App\Entity\Product\Product
                repository: App\Repository\ProductRepository

App\Entity\Product\Product extends Sylius\Component\Core\Model\Product and adds your fields. Doctrine inheritance (single-table) carries it through. This is the primary extension point — do not fork the vendor models.

Service decoration. Every business service in the bundle is a named service (sylius.order_processing.order_processor, sylius.promotion_processor, sylius.checkout.*). Override with decorates: rather than redefining:

App\Service\OrderProcessor:
    decorates: sylius.order_processing.order_processor
    arguments: ['@App\Service\OrderProcessor.inner']

Decorator chains get deep — keep a written inventory.

State machine config, not code. Order and payment workflows are Symfony Workflow configs (YAML) in vendor/sylius/core-bundle/Resources/config/app/workflow/. Add states, transitions, callbacks via your own sylius_order workflow config in config/packages/. Business logic lives in callbacks (sylius_order_transition_*) and guards, not in controllers. Debug with bin/console debug:workflow sylius_order.

Form and grid extension types. Sylius exposes AbstractTypeExtension/AbstractExtension base classes so you can add fields without replacing form types. Grids live in config/packages/_sylius_grid.yaml — add columns/actions without touching the bundle's grid definitions.

Fixtures via sylius_fixtures. For local/dev data (channels, tax categories, shipping methods, product options), configure fixtures in config/packages/_sylius_fixtures.yaml. This is how you seed a testable store without hand-scripting Doctrine inserts.

API Platform integration (1.x). sylius/core-bundle wires API Platform resources for products, orders, carts, and customers. If you're fronting the platform over JSON (the only sane path from a Laravel host), your contract is largely the API Platform resource definitions in Sylius\Bundle\CoreBundle\Api. Override via attributes on your App\Entity\* subclasses.

Checkout flow. The checkout is a sequence of steps (sylius.checkout.*) with state machine transitions. Custom steps are added by tagging a service with sylius.checkout.step and registering a state. Do not add logic to the checkout controller — it's a thin driver over the state machine.

If you're a Laravel shop: the only viable day-to-day pattern is to run Sylius as a separate Symfony service and consume it over HTTP. Nothing in this bundle maps to Laravel's container, Eloquent, or lifecycle. Build an API client on your side and treat Sylius as a commerce backend-of-record.

Gotchas and Tips

• Category error is the #1 trap. The 22 stars / 0 dependents are not a maturity signal — nobody is supposed to require the split directly. Any review scoring this against Laravel packages is comparing across categories. Escalate to a "do we adopt Sylius?" decision.
• Never require sylius/core-bundle standalone with a looser constraint than the rest of the suite. Version skew between sylius/core-bundle and sylius/order-bundle produces opaque DI compilation errors ("service does not exist" deep in a compiler pass). Keep all sylius/* aligned via the platform constraint.
• Local patches to the split vanish on composer update. The subtree split regenerates from the monorepo. If you need a fix, either carry a permanent cweagans/composer-patches entry or push upstream.
• Doctrine mapping changes require cache clear + schema update. Sylius uses XML mappings under Resources/config/doctrine/. After overriding a model class, bin/console doctrine:schema:update --dump-sql first — STI/DiscriminatorColumn changes often need a migration, not an update.
• debug:container lies about decorated services. Use bin/console debug:container --show-private and debug:autowiring to confirm the decorator chain actually wraps the service you think.
• State machines are cached. After editing workflow YAML, bin/console cache:clear is required; the config compiler caches transitions hard. A stale workflow cache produces "transition not allowed" at runtime with no obvious cause.
• Fixture order matters. sylius_fixtures runs in declaration order; a channel fixture referencing a locale or currency must run after them. When your fixtures fail, dump the ordered suite with bin/console sylius:fixtures:list (if available in your version) or read the bundle's services.xml for load order.
• Extension points, in order of preference: resource override → service decoration → form/grid extension → event subscriber → compiler pass → fork. A compiler pass that touches Sylius services is a red flag in code review — it usually means someone fought the resource system.
• Doctrine Order entity name collision. Your App\Entity\Order will shadow sylius.order if you don't follow the resource-override pattern strictly. Follow the class namespace conventions in Sylius\Component\Core\Model\*.
• Upgrade windows are gated by Symfony LTS + Doctrine ORM + PHP. Check all three against the target Sylius major before planning a sprint. A Symfony constraint will block a Sylius upgrade and silently strand you on a security-patched-but-commerce-frozen version.
• Ramp-up is non-linear. Symfony DI compilation, Doctrine mapping inheritance, and Sylius' resource/state-machine/grid trio are the gates. A mid-level Laravel developer is not productive here for a quarter. Budget for it, or adopt the service-isolation pattern and hire/pair a Symfony engineer.
• Support surface is upstream. Issues filed against Sylius/SyliusCoreBundle go nowhere. Route everything to Sylius/Sylius or commercial Sylius support.