Slider Bundle Laravel Package

Product Decisions This Supports

• CMS feature parity for marketing/content teams: If your product roadmap includes a content-managed hero slider, carousel, or promotional banner block, this bundle is a pre-built implementation of that primitive inside the Enhavo CMS — it removes the need to design, spec, and build slider block types, admin editing UI, and rendering from scratch.
• Build vs. buy (evaluate as "buy", but scoped): Treat this as a component of a larger platform purchase rather than a standalone library. The real decision is "adopt Enhavo CMS as our content platform," and the slider bundle is one of many ready-made block types that de-risks that decision.
• Roadmap sequencing for content-heavy products: If your near-term deliverables are marketing pages, landing pages, or editorial sites where non-technical users must compose promos without developer involvement, this bundle shortens the path to a self-serve editing experience.
• Use cases that fit: corporate/marketing sites on Symfony, multi-site content platforms, editorial properties where the slider is one block among many in a page-composition system.
• Use cases that do not fit: standalone single-page apps, non-Symfony stacks, or products that need only a slider and nothing else from Enhavo — in those cases the dependency weight far exceeds the feature value.

When to Consider This Package

Adopt when:

• You have already committed to (or are seriously evaluating) Enhavo CMS on Symfony — this is a subtree split of the main repo and is designed to be consumed as part of that ecosystem, not independently.
• You need CMS-managed slider/carousel content with an admin UI, and you value inheriting Enhavo's block/component conventions over rolling your own.
• You're comfortable with Sylius components and full-stack Symfony as baseline platform dependencies.
• Your team can read the main repository's docs and source, because this package's README is intentionally minimal.

Look elsewhere when:

• You want a standalone slider library. Zero stars, zero dependents, and a README that says only "this is a subtree split" mean there is effectively no independent user base, no external issue traffic, and no community support surface. A dedicated JS slider (Swiper, Splide, Glide) or a lighter CMS block will be a far better fit for a self-contained need.
• You need independent release cadence or versioning guarantees. Subtree splits inherit the main repo's release rhythm; you cannot pin, patch, or negotiate against this package on its own terms.
• You require vendor accountability, SLA, or a support contract. MIT-licensed, community-maintained, no dependents — support is best-effort via the main Enhavo repository.
• Your stack is not Symfony/Enhavo. Integration cost is likely to exceed the value of a single UI block.
• You need proof of production adoption. The signal here is weak; validate by inspecting the main Enhavo repo's activity, release history, and any reference sites before betting roadmap on it.

(Note: with an opportunity score of 4.16 and negligible ecosystem signals, treat this as a strategic evaluation of Enhavo as a platform, not a package-level adoption decision.)

How to Pitch It (Stakeholders)

To executives — one paragraph:

"Enhavo is an open-source, MIT-licensed CMS built on Symfony that ships a library of ready-made content blocks — this slider bundle is one of them. It isn't a product we'd buy or a vendor we'd depend on; it's an indicator of what we get out of the box if we standardize on Enhavo as our content platform. The strategic question isn't 'should we use this slider?' — it's 'is Enhavo the right CMS for our roadmap?' The upside is faster delivery of content-managed marketing surfaces and lower build cost for the editing experience. The risk is a small community and the fact that this package is a mirror of a larger repo, not an independently maintained library. I recommend a time-boxed spike against Enhavo rather than adopting this bundle in isolation."

To engineering — three points:

1. Not a standalone dependency. It's a read-only subtree split of enhavo/enhavo. Integration means committing to the CMS and its Symfony/Sylius baseline; issues and patches go upstream to the main repository.
2. Low external signal, so verify in the main repo. Zero stars and zero dependents tell us nothing about quality — check the main project's release cadence, test coverage, and Symfony version support before we plan against it.
3. Cheap to validate, expensive to unwind. A short proof-of-concept — install Enhavo, build a page with the slider block, measure admin UX and upgrade path — will settle the build-vs-buy question at low cost. What we must avoid is writing custom code against an unmaintained split with no fallback plan.