Archetype Laravel Package

Product Decisions This Supports

• Feature scoping for template-driven generation. The archetype concept — define a reusable template once, then instantiate many concrete entities from it — maps directly onto features product teams routinely queue: product/variant generation from a configurable template, catalog presets, plan/SKU matrices, tenant or workspace scaffolding, and bulk fixture/demo-data seeding. Reading this component gives you a working domain model (archetype → configured values/options → generated instances) you can reuse as a design reference instead of inventing the vocabulary in a planning meeting.
• Build vs. buy vs. borrow, decided honestly. This is a borrow the idea, build the code case. It is not a viable buy: no vendor, no support contract, no release cadence. Its value to a roadmap decision is as prior art that de-risks an estimate — "this shape of feature has been built before, here is the data model, here is why it was eventually folded into the core product" — which is often worth more than a dependency.
• Prioritisation signal for configurator work. If your backlog contains "let admins define a template and spin up N variants," this component is evidence the abstraction is real and that naive implementations get complicated fast (validation of template completeness, partial generation, rollback when one instance fails). That argues for scoping a spike rather than a "small ticket."
• Legacy archaeology and dependency hygiene. If you inherited a Sylius-based or Sylius-adjacent codebase, this tells you what an old archetype table/service was for and whether it is safe to delete. That is a maintenance-budget decision, not a product one, but it consumes roadmap capacity if ignored.
• What it does not support. Any decision that assumes ongoing maintenance, security patching, PHP/Laravel version compatibility, or community answers to questions. Archived, read-only, and zero dependents means the support surface is your own team, permanently.

When to Consider This Package

Consider it (as reading material, not as a dependency) when:

• You are designing a templating or generation feature and want a compact, MIT-licensed reference implementation of the archetype pattern to sanity-check your own model before committing to a schema.
• You are auditing a legacy Sylius footprint and need to understand an existing archetype component, its persisted shape, or why a table exists.
• You need to confirm whether something in your tree already pulls it transitively, so you can plan removal rather than continue carrying it.
• You are explicitly mining patterns, and the team is comfortable translating an older, framework-coupled design into idiomatic Laravel (service class + Eloquent relations + a validation layer + a transactional generator).

Look elsewhere when:

• You need a maintained runtime dependency. Zero dependents, five stars, archived status, and a read-only subtree split all point the same way: no upstream issue tracker here, no releases you control, no compatibility guarantees against current PHP or Laravel.
• Your requirement is a shipping product configurator or PIM capability. Commercial PIM/commerce platforms solve this with support and an upgrade path; a copied pattern does not.
• Your team would naturally reach for Laravel-native primitives anyway — factories, seeders, DTOs, value objects, config objects, queued jobs with transactions. For most Laravel codebases, an in-house implementation of the same idea is smaller, clearer, and yours to maintain, which is a better trade than inheriting an abstraction designed for a different framework's conventions.
• There is any chance the decision will be defended later with "but we adopted a package." Adoption carries an implicit maintenance promise you cannot keep here.

How to Pitch It (Stakeholders)

To executives: This is a small, archived, MIT-licensed reference component from the Sylius commerce platform — not a product we can adopt. It has no maintainers we can reach, no dependents, and is explicitly read-only. Its only value to us is as cheap prior art: it shows how a "define a template, generate many items from it" feature has been modelled before, which helps us estimate and de-risk a capability our customers have asked for. Recommendation: approve a short engineering spike to review it and prototype the pattern in-house; do not approve it as a dependency, and do not let it sit on any critical path.

To engineering: Treat this as source code to read, not code to install. It is a subtree split of a component inside the Sylius monorepo — issues and PRs live upstream, and this repo is a distribution artefact that has been archived. The idea worth extracting is narrow and portable: a template entity that owns attribute and option definitions, validated for completeness, then consumed by a generator that creates N concrete instances inside a transaction, with clear failure semantics when one instance is invalid. That is a few days of Laravel work using Eloquent relations, a form request or DTO for template validation, a generator service, and a job for bulk runs. The code is MIT, so reuse with attribution is fine, but a clean reimplementation will be smaller than adapting theirs. Deliverable of the spike: a one-page model comparison and an estimate, not a merged dependency.