Assortment Bundle Laravel Package

Product Decisions This Supports

• Catalog domain modeling (build vs. buy, feature design): The bundle defines the vocabulary most commerce products eventually need — product → variants → properties (descriptive attributes) and options (the combinatorial axes that generate variants, e.g. size/color). Even as a dead package, it is a useful reference spec when writing your own catalog schema or evaluating a vendor's.
• Variant generation scope: Supports the decision of whether to model configurable products as option-driven variant matrices (SKU-per-combination) versus simpler flat SKUs — a choice that drives inventory, pricing, and merchandising roadmap for years.
• Ecosystem bets: Its existence is an argument for not hand-rolling assortment logic in-house and instead adopting a maintained commerce core (Sylius 2.x components, or a Laravel-native equivalent). Its archival is an argument for buying into maintenance, not a particular historical bundle.
• Build-vs-maintain triage: If this appears in a dependency audit, it supports a remediation decision (replace, vendor, or delete) rather than a feature decision.
• Not supported: Any new-feature roadmap item. Zero dependents, 20 stars, Symfony2-era, and archived means it carries no adoption signal and no maintenance guarantee — it should not anchor a commitment.

When to Consider This Package

Legitimately consider only when:

• You are maintaining a legacy Symfony 2.x application that already requires it, and you need to understand or temporarily stabilize catalog behavior ahead of a migration.
• You want read-only reference material — a working historical example of assortment modeling — while designing a modern catalog schema or writing a migration map for existing product data.
• You are doing archaeology on an old Sylius install and need to trace where product/variant/option tables and semantics originated.

Look elsewhere when:

• The project is greenfield or Laravel-based. This is a Symfony2 bundle, not a Laravel package — it will not drop into a Laravel app, and Composer's Symfony framework constraints will fight you.
• You need security patching, PHP 8 support, or any support commitment. Archived means no fixes, no releases, no issue triage.
• Scope is a real catalog (thousands of SKUs, localization, multi-channel pricing, PIM integration). Evaluate Sylius 2.x product components, a PIM (e.g. Akeneo) if merchandising is the hard part, or Laravel-native commerce options (e.g. Lunar) if the stack is fixed.
• Your catalog is small and stable — a handful of tables and a variant matrix may be cheaper to own than any dependency.

How to Pitch It (Stakeholders)

To executives: This is a reference artifact, not a dependency. It is an archived, low-adoption (20 stars, zero dependents) Symfony2-era bundle with no maintenance path — adopting it would create unpatched risk with no offsetting strategic value. It is useful only as a design input for how we model products, variants, and options.

To engineering: Do not add this to composer.json. It targets Symfony2/PHP 5.x, is abandoned upstream, and is superseded by Sylius's current product components. If it is already in the tree, treat it as migration debt: capture the schema and semantics we depend on, map them to a maintained target, and plan removal.

Recommendation: Treat as buy-in-to-a-maintained-core, not build-on-this. Use it to justify the "buy/adopt a maintained commerce core" line item, or to scope a lean in-house catalog if our assortment needs are genuinely simple. If it's in production today, fund a migration rather than a workaround.