Theme Bundle Laravel Package

Product Decisions This Supports

• Ecosystem bet, not a package bet. This bundle informs a single decision: whether to standardize on Enhavo CMS (Symfony full-stack + Sylius components) as our content platform. The theme bundle itself is a subtree split — a Composer-facing slice of the monorepo — so it enters our dependency graph only as a consequence of that larger decision.
• Multi-brand / white-label roadmap. If we need per-tenant, per-brand, or per-channel theming (distinct templates, assets, and overrides resolved at runtime), Enhavo's theme layer is the mechanism that would deliver it. That makes this bundle a useful signal for how theming is modeled in the stack, not a candidate for adoption on its own.
• Build vs. buy for theming. The buy path is "inherit Enhavo's theme resolution conventions"; the build path is "write our own Twig namespace/theme resolver on top of stock Symfony." Adopting Enhavo collapses this work to configuration — but only if we adopt Enhavo.
• Commerce-adjacent content use cases. Enhavo's Sylius lineage points at catalog/marketing pages sitting next to transactional flows: product content, landing pages, editorial blocks, campaign microsites. Useful when scoping whether one platform can serve both content and commerce teams.
• Architecture and vendor-risk review. 1 star, 0 dependents, read-only, README-only maturity. This is a data point that the ecosystem is small — a genuine input to a "do we want a niche platform?" discussion, and a reason to keep an exit ramp (standard Twig templates, portable content schema) regardless of choice.

When to Consider This Package

Consider it only when:

• We have already committed to Enhavo CMS and are pulling bundles in as transitive dependencies. At that point this is an implementation detail, not a selection.
• We need Enhavo's specific theming conventions — theme directories, template/asset override precedence — and want to stay on the supported path rather than fighting the framework.
• We are patching or debugging an Enhavo-based application and need to inspect this bundle's source. Note the subtree split is read-only: fixes belong in the main repository, not here.

Look elsewhere when:

• Any standalone or framework-agnostic use. The bundle is explicitly a [READ-ONLY] split with a placeholder README. There is no documented public API, no usage guidance, no stated versioning or support policy. It is not designed to be consumed outside Enhavo.
• We need to evaluate theming as a capability. There is nothing here to evaluate — the README contains no feature description. Go to the main Enhavo repo and its docs, and judge the platform there.
• We are on Sylius but not Enhavo. Use Sylius' own theme bundle rather than reaching into a CMS-specific split.
• We are not on Symfony at all. Non-starter.
• Support, security response, or community depth is a requirement. Near-zero adoption means we would be largely on our own; any assessment should be made against the monorepo's activity, not this mirror's metrics.
• We want a proven, widely deployed theme component. This is not that.

How to Pitch It (Stakeholders)

To executives: This is not a product we can adopt — it's an internal building block of Enhavo CMS, published to Composer so applications can install pieces of the framework separately. Its near-zero adoption metrics (1 star, no dependents, README-only documentation) tell us nothing about the bundle and something modest about the ecosystem: Enhavo is a small, niche platform. The real decision on the table is whether Enhavo CMS is the right content platform for us, evaluated on feature fit, total cost, and vendor risk. My recommendation: treat this as a footnote to that decision, not a candidate in its own right. If Enhavo is not already on the shortlist, close this out — the cost of investigating it exceeds any plausible upside.

To engineering: Do not fork, do not open PRs here, and do not pin to this repo directly. It's a subtree split of the Enhavo monorepo — read-only by construction, with fixes landing upstream. Consume it only as a transitive dependency of enhavo/enhavo, and pin Enhavo versions deliberately. Expect little external documentation and plan to read source. If we do adopt Enhavo, isolate the theming layer behind our own template conventions so that swapping platforms later is a contained piece of work rather than a rewrite.