Variation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for variant modeling: This bundle is the reference shape of the "options → option values → variants" model — Size × Color expands into concrete SKUs, each with its own price, inventory, and SKU code. That schema is the decision input for whether we model variations ourselves (an options table, an option_values pivot, a variants table with an option-value tuple) or adopt Sylius wholesale. Even if we build, seeing the battle-tested shape de-risks the build.
• PDP feature scoping: It pins down what the product detail page must do — option selectors, per-variant availability and pricing, disabling impossible combinations, and generating variants on save without duplicating existing ones. Use it to size the selector/validation work rather than discovering it mid-sprint.
• Catalog, pricing, and inventory architecture: Variation-level price and stock is the reason every downstream integration (cart, warehouse, fulfillment) must key on the variant, not the product. That identifier choice is expensive to reverse once orders exist, so it belongs in the architecture review now.
• Roadmap sequencing: It clarifies the dependency order — catalog → variations → pricing → cart line items → fulfillment. Variation support is a blocking prerequisite for bundles, multi-pack SKUs, and marketplace-style listings.
• Combinatorial governance: The bundle does not solve variant explosion; the number of variants grows multiplicatively with each option axis. That is a product-modeling policy decision (caps on axes, sparse creation, lazy generation), and this package is useful mainly for making that conversation concrete.
• Platform coupling risk: Because the artifact is archived and read-only, it also feeds the broader "how coupled to Sylius's data model do we want to be?" decision, not just this component.

When to Consider This Package

Consider using it as a reference when:

• We are on Sylius or seriously evaluating it and want to understand or extend its variation domain model. Note the supported path is to depend on sylius/sylius — since Sylius 1.0 this code lives in ProductBundle/sylius/product (Option became ProductOption, Variant became ProductVariant), so the split repo is history, not a dependency.
• We want a proven schema and a set of domain rules to benchmark a homegrown implementation against — especially the VariantGenerator's cartesian expansion that reuses existing matching variants instead of duplicating them. That one routine is worth porting nearly verbatim.
• We are building a catalog that genuinely needs multi-attribute variants (apparel, configurable hardware, tiered subscriptions), not a single "size" or "plan" field.

Look elsewhere when:

• We are not on Sylius. Do not composer require an archived, read-only subtree split with 6 stars and zero dependents. It extends Symfony's bundle/kernel and assumes Doctrine ORM and Sylius's resource layer — none of which map onto Laravel's service providers, Eloquent, or facades. Expect dependency resolution failures.
• We need maintained support. The archive flag is decisive: no security patching, no compatibility updates, no issue triage, and commit history is a mirror of the monorepo. Anything shipped against it inherits unowned risk.
• Our variation needs are simple. A single option with a handful of values is a column and a lookup table; a full option/variant graph adds query complexity and admin UI surface for no user-visible benefit.
• We need variants for non-catalog entities (pricing plans, service tiers, shipping methods). The model is shaped around sellable products, and forcing other domains through it fights the abstraction.

How to Pitch It (Stakeholders)

To executives: This is not a package we buy or deploy — it is a design reference. It shows how a mature e-commerce platform (Sylius) structures product variations: which combinations exist, what each costs, and what's in stock. Reading it costs us days; getting this model wrong costs a re-platforming project once orders, inventory, and pricing are all keyed to the wrong identifier. Recommendation: use it as input to our catalog architecture decision, budget zero licensing cost, and explicitly not add it as a dependency. It is archived, has no support contract, six stars, and zero dependents — that is a documentation artifact, not a dependency.

To engineering: Treat sylius/variation-bundle as read-only reference documentation. It is an archived subtree split of the Sylius monorepo; the code now lives in sylius/product, so if we ever adopt Sylius we take the parent and get this for free. Use it to pressure-test our schema: how we represent options and option values, how we generate and prune variant combinations, and where price and stock attach. If our needs are simple, don't import the full graph — borrow the shapes, keep the queries cheap, and keep the variant-generation reuse logic (match existing combinations rather than recreate them). Realistically this is a port of a small domain — options, option values pivoted to products, a variants table with an option-value tuple, and a cartesian generation service — a few days of work, not weeks, and it gives us full ownership. Flag any proposal to require this package directly as a risk, not an implementation detail.

One-line summary: Valuable as a blueprint for product variations, dangerous as a dependency — mine it for the data model and the generation logic, don't ship it.