Archetype Bundle Laravel Package

Product Decisions This Supports

• Catalog modeling for configurable products. The archetype pattern is the canonical answer to "how do we let merchants define a product family once and reuse it?" — a template that pre-assigns attributes, options, and catalog settings, which then drives variant/SKU generation. Every roadmap conversation about configurable products (apparel size/color matrices, electronics configurations, tiered B2B catalogs) should start from this model rather than a bespoke spec.
• Build vs. buy vs. borrow. This package is a reference implementation, not a dependency. It shortens the build-vs-buy debate by showing the full domain shape — archetype → attributes/options → product variants — in working code you can read in an afternoon. That's cheaper than a vendor evaluation and more concrete than a requirements doc. Use it to size a native implementation and to argue against commissioning a bespoke "product template engine."
• Onboarding and admin UX decisions. The archetype-first flow (pick a template, then edit) versus a blank-slate product form is a product decision with measurable impact on time-to-first-listing and data consistency. This bundle is evidence of what the pattern looks like when editors, not developers, own catalog setup.
• Migration scoping. If any legacy Sylius estate exists, this defines a discrete migration ticket: inventory archetype usage, map to core ProductAttribute/ProductOption/ProductVariant, and verify SKU generation, pricing inheritance, and stock behavior post-move.
• Roadmap de-prioritization. The concept was absorbed into Sylius core and the standalone bundle retired — a clear signal that option-driven variant generation is table stakes, not differentiation. Redirect that budget to merchandising, pricing rules, or B2B tiering.
• What it does not support: bundle/kit products, made-to-order configurators with arbitrary attribute pricing, or anything on a non-Sylius stack. Don't let a catalog requirement get bent to fit this pattern.

When to Consider This Package

Consider it as a reading reference in exactly two situations:

1. You are maintaining or migrating a legacy Sylius (0.x–1.x era) codebase where archetypes are still wired into product creation. Read the model, builder, resolver, and registry to understand the schema and inheritance logic before porting to core entities. You read it; you do not depend on it.
2. You are specifying a native product-template feature in Laravel and want a concrete, battle-tested domain shape to write your spec against — tables, pivot assignments, hydration of a new product form with preselected values. Treat the repo as a design document with an MIT license.

Look elsewhere — decisively — in every other case:

• Archived and read-only. No security patches, no PHP 8 support, no modern Symfony or Doctrine compatibility. Unmaintained code is a liability with a scheduled failure date.
• 4 stars, 0 dependents. Effectively zero ecosystem validation and no community to lean on for bugs or migration guidance.
• Not a Laravel package. It's a Symfony bundle bound to the DI container, compiler passes, Doctrine mappings, and Sylius ResourceBundle. Composer may install it; it will not boot. There is no adapter path short of a rewrite.
• Superseded by Sylius core. Adopting it re-introduces a dependency the vendor deliberately removed.
• Any greenfield build. Archived package on a new project is an automatic architecture-review rejection.

The 8.48 opportunity score reflects that variant archetypes matter in commerce, not that this package is worth adopting. Read the score as a demand signal, not a build signal.

How to Pitch It (Stakeholders)

To executives: "This is a retired component from a commerce platform we don't run. It's archived, has no maintainers, and no adopters — adding it would create a dependency with a known expiry date and no support path. Its value to us is conceptual: it codifies the standard way configurable products are modeled, which we can use as a checklist when specifying our own catalog requirements. Recommended spend is near zero — a short spike only to confirm whether any legacy system still depends on it. If not, we close it and move on."

To engineering: "Archived, read-only, 4 stars, 0 dependents — do not add this to composer.json. It's a Symfony bundle; it does not run on Laravel. Use it as a spec: archetype (template) carries attributes, options, and catalog settings; products instantiate the archetype and inherit those assignments; variant matrices are generated from the option set. That pattern is already in Sylius core (ProductOption → generated ProductVariant set), so on a Sylius estate we migrate to core, and on Laravel we build a small native module — product_archetypes table, pivot tables for attribute and option assignments, and a service that hydrates a new product form with preselected values. That's a well-bounded feature with tests, not a framework integration. If you find legacy archetype usage, scope it as a migration ticket with a defined exit date."

One-line ask: approve a time-boxed spike to confirm whether any legacy archetype usage exists; if none, close this out and mark the item "reference only — no adoption."