Shop Bundle Laravel Package

Technical Evaluation

Architecture fit cannot be assessed against Laravel, because this is not a Laravel package. enhavo/shop-bundle is a Symfony bundle and a read-only subtree split of the Enhavo CMS monorepo. There is no service provider, no config/shop.php published config, no Laravel package discovery. It is designed to be registered inside a Symfony kernel via bundles.php and bootstrapped by Enhavo's application scaffolding. The dependency graph it assumes is Enhavo core bundles (resource, routing, block, media, user/permission) plus Sylius components for commerce primitives (product, order, pricing, cart/checkout). A TPM should treat "Laravel compatibility" as zero and make that finding the first line of the decision record — otherwise the entire evaluation is being scoped against the wrong stack and every subsequent estimate is fiction.

Integration feasibility, ranked by realism:

1. Existing Enhavo/Symfony application — feasible and idiomatic. The bundle is the natural next module; consumption should happen from the monorepo, not the split, so issues, changelogs, tests, and PRs stay in one place.
2. Non-Enhavo Symfony application — low feasibility. You inherit the Enhavo bundle graph (resource/block/media abstractions) whether or not you want the CMS, plus Sylius component wiring. Not a composable à-la-carte library.
3. Laravel application — effectively a rewrite. You would be reimplementing Enhavo's resource/CRUD/routing abstractions and Sylius component wiring inside Laravel's container. For a dependency with zero stars and zero dependents, that is not a TPM-approvable effort.

Technical risk is high and concentrated in provenance, not code quality. The code may well be fine — it ships inside a working CMS — but the evidence available to a decision-maker is thin: read-only split (issues and PRs land upstream; this repo's tracker is a dead end), zero stars and zero dependents (no observable production usage, no third-party examples), no documentation beyond a logo and a pointer, implicit coupling to Sylius component majors that have historically carried breaking changes, and single-vendor bus factor. For a module that touches carts, orders, and pricing — money — the absence of community validation is an unacceptable evidence gap absent an internal spike.

Key questions to resolve before any commitment:

• Exact composer.json constraints: PHP major, Symfony major, Sylius component majors, Doctrine ORM/DBAL. Are any already EOL?
• Does the bundle compile and run standalone, or does it hard-require Enhavo core bundles at container compile time?
• Which parent release tag does split HEAD correspond to, and how far behind is it?
• Does it ship migrations, fixtures, and admin UI, or domain logic only?
• Is there a supported upgrade path across Enhavo majors, and has the upstream project released in the last 6–12 months?
• Who owns order/checkout persistence — Sylius proper, or a local reimplementation?
• What is the frontend/admin build toolchain assumption (Twig, asset pipeline, JS bundler)?

Integration Approach

Stack fit. The honest statement is PHP + Symfony full-stack + Doctrine ORM + Twig + Sylius components. Against a Laravel target (Blade/Inertia, Eloquent, service providers) the fit is zero on container, ORM, and templating simultaneously — three independent incompatibilities, not one. Fit is high only where the application is already Symfony and preferably already Enhavo, in which case the shop bundle requires no architectural negotiation and the decision collapses to sequencing and version pinning.

Migration path. Do not plan a migration to this package from a Laravel codebase. Choose explicitly:

• Default recommendation: do not adopt for a Laravel target. Evaluate Laravel-native commerce or a headless service (Medusa, Saleor, Shopify headless). The Symfony bridge cost dwarfs the value of a 0-star bundle.
• If the org is committing to Symfony/Enhavo: adopt from the main repository via VCS or path repository, treat the split purely as a convenience mirror, and pin to an exact parent release tag.
• If only the commerce domain is wanted: skip this bundle and evaluate the underlying Sylius components directly. That isolates the dependency to a widely used, documented component set and avoids inheriting the CMS.
• Adapter layer: justified only under a hard business constraint mandating Enhavo's data model. Budget as a project, not a task.

Compatibility gate. The composer constraint matrix is the go/no-go, and it must be resolved before any design work. Verify PHP and Symfony majors against the current pinned versions, Doctrine ORM/DBAL against target databases, and Sylius component majors against whatever Sylius constraints other dependencies already pull — a version conflict here is a silent blocker that surfaces weeks into a spike. Confirm PHP extension requirements and whether the admin UI assumes a specific asset build toolchain.

Sequencing.

1. Framework-mismatch ruling (1 day). Publish in writing that this is a Symfony bundle, not a Laravel package. This kills the stated path cheaply and prevents sunk-cost drift.
2. Due-diligence spike (3–5 days). Read monorepo source, resolve the constraint matrix, confirm the container compiles with Enhavo bundles installed in a bare Symfony app, run whatever tests exist.
3. Decision gate: adopt / components-only / reject. Record the rationale.
4. PoC: one vertical slice — catalog → cart → order persist — in a Symfony sandbox pinned to a parent release tag.
5. Dependency register: record the split-tag ↔ monorepo-tag mapping and a quarterly upstream-activity review.
6. Rollout behind a feature flag with a documented exit path to Sylius components alone.

Operational Impact

Maintenance. Maintenance does not happen in this repo — it happens in the monorepo. Your upgrade cadence is therefore bound to a third party's release cadence, and your security posture is bound to their responsiveness on Sylius component CVEs. Institute a quarterly review of upstream release activity and Sylius constraint currency; if either stalls, flag the dependency at-risk and activate the exit plan. Internal cost is front-loaded into source reading, because documentation-driven onboarding is not available — budget a spike, not a rollout.

Support. No commercial support, no SLA, no visible maintainer bench beyond the upstream project, and an issue tracker on the split that is not actionable. Escalation is upstream community channels only. For a commerce surface handling money, orders, and inventory, this is the weakest dimension in the assessment and should be stated plainly to stakeholders rather than softened.

Scaling. Application-level scaling is conventional Symfony/Doctrine: horizontal PHP-FPM behind a load balancer, shared session/cache, read replicas for catalog reads. The bundle imposes no unusual scaling model. The risk sits in the CMS surface bundled alongside it — Enhavo's block/media abstractions can produce heavier queries and file-storage coupling. Load-test the storefront and checkout paths specifically; do not assume CMS read patterns generalize to checkout traffic.

Failure modes to design against.

• Upstream drift: split lags the monorepo; your pinned tag becomes unsupported. Mitigation: pin exactly, monitor upstream, be prepared to maintain a fork.
• Sylius CVE exposure: an EOL component major leaves you patching commerce code yourself. Mitigation: track component versions in the dependency register; set an explicit patching trigger.
• Container coupling: the bundle turns out not to be independently usable, dragging the full Enhavo CMS into your app. Mitigation: prove standalone compilation in the spike, before PoC.
• Silent scope expansion: adapter work estimated as days becomes quarters. Mitigation: gate the adapter as its own project with its own approval.
• Bus factor: a single small vendor project stalls. Mitigation: exit path to Sylius components documented and rehearsed at flag-flip time.
• Talent scarcity: few engineers have Enhavo experience; hiring and onboarding risk is real. Mitigation: keep the Symfony generalist requirement primary in job specs.

Ramp-up. Assume weeks, not days, for a competent Symfony engineer to be productive — not because the code is obscure but because there is no documentation, two opinionated abstraction layers (Enhavo resources, Sylius components) to internalize, and an admin UI whose conventions must be learned from source. Plan a senior-engineer-led spike with a written internal summary as the deliverable; that summary becomes the onboarding document the package does not provide. If the team is not already a Symfony shop, the ramp-up is the framework, not the bundle, and that is a hiring decision masquerading as a dependency decision.