Core Bundle Laravel Package

Product Decisions This Supports

• Commerce platform buy-vs-build. This package is the substrate of a full commerce domain — catalog, cart, checkout, orders, promotions, payments, shipping, tax. It informs the single largest roadmap decision a commerce product makes: adopt an opinionated platform (Sylius) versus compose narrower services or build bespoke.
• Framework direction, not library selection. sylius/core-bundle is a Symfony bundle, not a Laravel package, and it is a read-only subtree split of the Sylius/Sylius monorepo. The decision it supports is "do we standardize on Symfony + Sylius for commerce," not "do we add this dependency." For a Laravel roadmap this is a fork-in-the-road decision with multi-year consequences.
• Architecture and extensibility budgeting. The bundle split exposes where customization lives — Core, Admin, Shop, API, UI are separable surfaces, and overrides happen through service decoration, resource overrides, and state-machine configuration. That inventory of seams is the real input to an extensibility and maintenance-cost forecast.
• Headless vs. monolith commerce topology. For a Laravel product, the viable pattern is service isolation: Sylius as a standalone Symfony commerce backend-of-record behind an HTTP/JSON or message-bus contract. That is a product-architecture decision (second runtime, data federation for catalog and customers, sync model) with staffing and ops implications, not an integration detail.
• Roadmap scoping for commerce-adjacent features. Subscriptions, B2B tiered pricing, marketplaces, and promotions layered on Sylius are extensions of an existing domain model — feasible but coupled. This informs whether those features are "configure the platform" or "greenfield a service."
• Vendor-risk and upgrade-calendar planning. Sylius majors align with Symfony LTS cycles, so upgrades cluster into forced windows across roughly a dozen sylius/* packages. This drives release-train planning, staffing for Symfony depth, and whether to budget commercial Sylius support.
• Procurement/dependency-scoring hygiene. Stars (22) and dependents (0) are structurally meaningless for a read-only split — nobody is supposed to depend on it directly. A PM should flag any scorecard that ranks this artifact on those metrics as producing a false negative, and codify "never require sylius/*-bundle directly; require sylius/sylius."

When to Consider This Package

Consider it only as a downstream consequence of a platform decision:

• Sylius has already been chosen (or is the front-runner), and you need to understand what you're inheriting. You're evaluating the domain model, the override seams, and the upgrade surface — not shopping for a library.
• You need a full-stack, opinionated commerce platform you intend to extend heavily — marketplace variants, B2B pricing, subscriptions, complex promotion and tax rules — and you accept coupling as the price of coherence.
• The team is Symfony-fluent: Doctrine mapping, DI container compilation, and Sylius' Resource/Grid/StateMachine conventions. Extension requires all three.
• You are standing Sylius up as a standalone commerce service and integrating over an API boundary, which is the only pattern that preserves a Laravel host application.
• You're defining dependency policy and need a concrete example of why transitive, split-published artifacts must not be scored or pinned independently.

Look elsewhere when:

• The host application is Laravel-native. The stack mismatch dominates any feature overlap; evaluate Laravel commerce options (Lunar, Bagisto, Aimeos, Vanilo) or a headless commerce API instead. The adapter story here is effectively nonexistent.
• You want a single capability, not a platform. Pulling in order state machines or pricing rules without the rest of Sylius is not a supported consumption path — the components are interdependent.
• You want a thin, API-first backend. Sylius is a full application; a headless-first product is better served by a commerce API.
• You expect to fork and patch. You'd have to fork the monorepo; the split is regenerated and will not accept your changes.
• Your procurement or scoring process gates on stars/dependents. Those metrics will mislead the review here.

How to Pitch It (Stakeholders)

To executives: This is not an open-source dependency win — it's an internal build artifact of the Sylius commerce platform, published so Composer can resolve the pieces. The actual decision on the table is whether we standardize on Sylius for commerce. Frame it that way: compare Sylius against renting a commerce platform (Shopify, Medusa, Spree) and against a bespoke build on total five-year cost of ownership — licensing, staffing, upgrade windows, and the switching cost of reversing course. Adopting Sylius means inheriting a large, coupled domain model with genuinely deep commerce features; that is an asset if we plan to customize heavily and a liability if we want something small. For a Laravel shop, the honest recommendation is either to close this as out-of-scope or to fund a separate Sylius platform evaluation with its own budget, Symfony staffing plan, and upgrade ownership.

To engineering: Treat sylius/core-bundle as transitive and invisible. Require sylius/sylius at the platform level, keep every sylius/* constraint identical, and never consume a single piece standalone or pin the split independently — a local patch to a read-only split is silently lost on the next composer update. Customization happens at bundle seams: service decoration, resource overrides, state-machine configuration. Keep a written inventory of every override, because that inventory is our true upgrade cost and the thing we'll be negotiating against Symfony LTS cycles. If our application is Laravel, don't attempt an in-process integration — isolate Sylius as its own Symfony deployable behind an API contract, and plan the ramp-up realistically: a mid-level Laravel developer is not productive in this stack for a quarter or more, with Symfony DI and Sylius' Resource, Grid, and StateMachine abstractions as the gating concepts.