Slider Bundle Laravel Package

Technical Evaluation

Architecture fit. enhavo/slider-bundle is not a Laravel package — it is a Symfony bundle belonging to the Enhavo CMS, built on Symfony's full-stack conventions and Sylius components. It is distributed as a read-only subtree split of the enhavo/enhavo monorepo, which means the artifact here is a publishing mechanism, not an independently governed library. Architecturally it assumes: Symfony's bundle/DI container and compiler passes, Doctrine ORM entities and migrations, Twig templating, Enhavo's own block/renderer abstraction, and the Enhavo admin UI. None of those primitives exist in a Laravel application, so the bundle cannot be installed and used as-is. The realistic fit is "reference implementation and data model to copy from," not "dependency to require."

Integration feasibility. Low for direct adoption; moderate for selective reuse. Concretely, a Laravel team could lift the concept — a slider entity with ordered slides, media references, and a renderer contract — in a few days. Anything beyond that (admin editing UI, block integration, publishing workflow) is coupled to Enhavo's admin stack and would need reimplementation in Blade/Livewire/Inertia + Eloquent. The absence of a functional README (the excerpt is a project blurb plus "this is a subtree split") means the actual surface area — service IDs, entity fields, config schema, template names — is undocumented and must be read from source.

Technical risk. High, concentrated in four areas:

• Governance: zero stars, zero dependents, read-only split. Issues and PRs are not accepted here; all activity is in the monorepo. Any fix you need is either upstreamed to a project you don't control or vendored locally.
• Versioning: subtree splits track monorepo releases; there is no visible standalone semver contract or changelog for this package. Constraint drift can appear without a package-level signal.
• Abandonment: Enhavo is a small-community CMS. Zero dependents is a weak adoption signal, not proof of quality, but it means no ecosystem to lean on when something breaks.
• Vendor coupling: pulling it in drags Doctrine and Symfony components into a Laravel app, creating container and autoload surface you will spend real time containing.
• The score of 0 versus an opportunity score of 4.16 is itself a flag — the heuristic sees a plausible capability but no evidence of adoption.

Key questions.

1. What is the actual PHP and Symfony version floor implied by the monorepo's current release?
2. Which parts are data model (portable) versus admin UI and block integration (not portable)?
3. Is there a documented HTTP/API surface, or is rendering strictly server-side Twig?
4. Who maintains Enhavo, at what cadence, and what is the release history over the last 12 months?
5. Is the slider capability differentiated enough to justify any porting effort versus a first-party Laravel implementation?
6. Are there license-compatible transitive dependencies that conflict with our existing stack?

Integration Approach

Stack fit. Poor at the framework boundary, adequate at the language boundary. PHP 8.x compatibility likely aligns, but the runtime model diverges: Symfony DI + Doctrine + Twig + Enhavo blocks versus Laravel's service container + Eloquent + Blade + whatever page/builder layer we use. There is no adapter layer that makes a Symfony bundle feel native in Laravel; anything we do will be a port or a sidecar.

Migration path. Three viable options, in ascending cost:

Option B is defensible only where Enhavo is already the CMS for some other property. Option C is the honest version of "using the package" — we take the design, not the code.

Compatibility. Laravel version is irrelevant to this package; the real constraints are PHP minor version, Symfony major version, and Doctrine ORM/DBAL ranges. These must be read from the monorepo's composer.json, not this split, since the split's manifest is generated. Expect conflicts with any Laravel app already pinning Symfony components via dev tooling.

Sequencing. (1) Timeboxed spike — read the monorepo source for the slider module, extract entity fields, ordering semantics, and renderer contract, ~1 day. (2) Decision gate against Option A: if our requirements are a subset of what a 100-line first-party implementation covers, stop. (3) If proceeding with C, land the schema and ordering/position semantics first with tests, then rendering, then any editorial UI. (4) Defer admin UI until editorial demand is proven. (5) Never add the bundle to composer.json as a runtime dependency in a Laravel app — vendor a copy only if we are literally forking logic.

Operational Impact

Maintenance. Effectively self-maintenance. The read-only split means we cannot patch upstream through this artifact; local forks diverge silently and become unupgradable. Budget for owning 100% of the code we adopt, from day one. For a Laravel team, that ownership includes translating any upstream Symfony-side change into our port on a best-effort basis — a recurring tax with no reciprocal benefit.

Support. Community-only, small community, no SLA, no commercial backing evident from the package metadata. Internal escalation path is "whoever read the source." Zero dependents means searching for prior art on failure modes will return nothing. This is the single largest operational objection; it is mitigated entirely by Option A.

Scaling. The slider concept scales fine — it is a small ordered list of media references, and read-heavy rendering caches well at the CDN or response-cache layer. The package itself contributes nothing to or against scaling, because its scaling characteristics are Symfony's and Enhavo's, and we would not be running either under Option A or C.

Failure modes. Ranked by likelihood and blast radius:

• Silent constraint drift (high likelihood, medium radius): a monorepo release shifts a Symfony or PHP floor; if we had adopted the bundle, an unrelated composer update breaks the build with a misleading error.
• Unpatchable defect (medium, medium): bug in slider logic, no accepted PR path here, requires fork-and-own.
• Orphaning (medium, high over a 2-year horizon): Enhavo activity ceases; the artifact remains installable but frozen and increasingly incompatible.
• Container/autoload bleed (low if we never require it, high if we do): Symfony bundle registration attempts inside Laravel fail at boot, not at install, producing confusing runtime errors.
• Documentation void (high, low radius): the README says nothing; every integration question costs a source dive.

Ramp-up. For a Laravel-fluent engineer, the package itself is a multi-hour source read — small codebase, but idiomatic Symfony with Enhavo-specific conventions. Meaningful ramp-up is on Enhavo's block/renderer model, which is the part we would be discarding anyway. Net: near-zero ramp-up required for Option A, roughly one engineer-day for Option C, and multiple engineer-days plus ongoing operational surface for Option B.

Recommendation. Do not adopt as a dependency. Treat it as a design reference for a ~1-week first-party Laravel slider, and revisit only if we standardize on Enhavo as a CMS elsewhere in the portfolio — in which case Option B becomes coherent for the first time.