Shop Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for content-led commerce. This bundle lets you bolt shop capability onto an Enhavo CMS instead of integrating a separate commerce platform. It informs the decision: one integrated editorial + commerce system, or two best-of-breed systems joined by an integration layer?
• Feature scope: content-first storefronts. It fits merchandising driven by editorial pages, landing pages, and rich content — brand/D2C sites, lookbooks, campaign storefronts, B2B portals with heavy documentation — rather than large catalog-grid retail.
• Reuse over rebuild. Because it rests on Sylius components, it supports reusing a proven PHP commerce domain model (cart, pricing, order concepts) without adopting the full Sylius application and its conventions.
• Roadmap sequencing. If Enhavo is already the content platform, this bundle is the natural commerce extension point — reframing the question from "which commerce vendor do we onboard" to "when do we add commerce to the CMS."
• Dependency governance and ownership. It is a read-only subtree split of a monorepo, so it forces a PM-relevant decision about where issues and fixes live (upstream, not here) and how versions are pinned against parent releases. That is a governance decision, not a feature decision.
• Investment framing. Adoption implies a standing Symfony/PHP engineering commitment — a "we own the maintenance" choice that belongs in headcount and roadmap planning, not just a backlog ticket.
• Framework-fit check. Despite being evaluated as a "Laravel/PHP package," it is a Symfony bundle with no Laravel service providers, config, or auto-discovery. For a Laravel roadmap this is a rejection input, not a build option — surfacing it early prevents a mis-scoped epic.

When to Consider This Package

Consider it when:

• You are already running Enhavo (or have firmly committed to Symfony full-stack) and want commerce as an in-platform capability rather than an external service.
• You want Sylius-grade commerce primitives without adopting the whole Sylius application.
• You have in-house Symfony/PHP engineers who can read source — documentation here is effectively a logo, a paragraph, and a pointer to the main repository.
• Your commerce needs are moderate and content-coupled (catalogs, carts, editorial merchandising), not deep (multi-warehouse fulfillment, complex tax jurisdictions, marketplace payouts).
• You are comfortable treating it as a "source-available reference implementation": pin a version, track upstream, expect to read code.
• You will consume it from the main monorepo — that is where issues, changelogs, tests, and PRs actually live.

Look elsewhere when:

• The target app is Laravel. Fit is zero on container, ORM, and templating simultaneously; bridging means reimplementing Enhavo's resource/routing/block abstractions. Not a defensible spend on a 0-star dependency.
• Community signal matters. Zero stars, zero dependents, and a read-only split mean no independent ecosystem, no third-party plugins, and no external validation — a hiring and onboarding risk.
• You need vendor support, SLAs, or a published release cadence. Nothing in the metadata suggests any of these; for money-handling code that is the weakest part of the case.
• Your team is not a Symfony shop. The learning curve is the framework, not the bundle.
• Commerce is the core product. Full Sylius, Shopware, Adobe Commerce, or headless options (Medusa/Saleor) carry richer roadmaps and larger talent pools.
• You expect documentation-driven onboarding. Budget a spike, not a rollout.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed commerce module for the Enhavo CMS, built on the same Sylius components used by established PHP commerce systems. Strategically it enables a single platform for content and selling — fewer vendors, less integration surface. The trade-offs are ownership and evidence: no meaningful community (zero stars, zero dependents), a read-only mirror of a larger repository, and support coming entirely from our own engineers or upstream Enhavo. It also only fits Symfony/Enhavo — it is not a Laravel package. Recommendation: fund a time-boxed spike, not a platform commitment. Two to three weeks to prototype catalog-to-checkout in a branch, measured against our actual requirements, before choosing between "extend Enhavo" and "buy dedicated commerce."

To engineering: It is a subtree-split Symfony bundle on Sylius components — real, reusable domain code with essentially no documentation. Value is direct source access and framework fit; cost is that we own upgrades, pinning, and bug fixes, and we must contribute upstream rather than to this repo. Before committing, resolve the composer constraint matrix (PHP, Symfony major, Sylius component majors, Doctrine/EOL status), confirm the bundle compiles without the full Enhavo bundle graph, and identify which parent release tag the split HEAD corresponds to. Ask for an estimate of ongoing maintenance load, and confirm we are standardized on Enhavo/Symfony before considering it at all.