Nova Carousel Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova Card — a thin PHP class extending Laravel\Nova\Card paired with a compiled Vue component registered through Nova's asset pipeline. It carries no domain logic, no data model, no migrations, no API surface. Its entire footprint is presentational: a rotating panel of content blocks on the Nova dashboard. That means it fits only if the host application is already running Laravel Nova (a paid, per-project licensed product), and it delivers discretionary admin polish rather than business capability. The low opportunity score (24.32) is consistent with that: the widget is nice-to-have, not a lever.

Integration feasibility. Mechanically trivial — composer require, register the card in NovaServiceProvider::dashboards(), optionally publish assets. The real variance is Nova major version. Nova 3 is Vue 2; Nova 4/5 rebuilt the front end on Vue 3 with a different compilation contract. This card wraps vue-carousel, a Vue 2 component whose last release was around 2020. A card built on that stack will not render under Nova 4+ without a rewrite. Because such cards typically ship pre-built dist/ assets, compatibility is binary and version-specific: either the committed bundle matches our Nova version, or the card fails silently.

Technical risk. High relative to the value delivered.

1. vue-carousel is unmaintained — no security patches, no Vue 3 path, no reduced-motion or keyboard support.
2. Single maintainer, 9 stars, 0 dependents: no downstream field-testing, no evidence of production use, no community safety net.
3. Nova's private asset-compilation conventions change between majors; a stale or missing dist/ produces a blank card with no server-side error.
4. Slide content is likely defined in PHP or injected markup — unescaped HTML is a stored-XSS vector for anyone who can edit the dashboard (usually admins, so bounded but real).
5. Carousel accessibility is weak in this library generation (autoplay, no pause control), a WCAG concern even for internal tools.

Key questions before adoption.

• Which Nova versions are supported, and is that compatibility tested in CI against the latest release?
• Are compiled assets committed, and can we rebuild them with the current Nova toolchain?
• What is the last commit date and the state of the issue backlog? Is there a Nova 4/5 branch?
• How is slide content authored — hardcoded PHP, config file, or database? Can it be localized and permission-scoped?
• Does it sanitize URLs/HTML and lazy-load large images?
• What happens to the rest of the dashboard bundle if this component throws on mount?

Integration Approach

Stack fit. Fits only a Laravel application already on Nova. No database changes, no queues, no external services, no runtime dependencies beyond the bundled JS. If we are not on Nova, the conversation ends — it is not portable to Blade, Inertia, or Livewire dashboards.

Migration path. Purely additive; there is nothing to migrate. Install behind a feature flag or in local/staging only, validate rendering, then promote to a single internal dashboard. For teams on Nova 3 it is a drop-in; for Nova 4/5, treat it as a reference implementation to fork, not an installable dependency.

Compatibility. Pin the package and the Nova minor version, and treat the compiled asset as a locked artifact. Confirm the PHP and Laravel constraints against our matrix. Because the build pulls in vue-carousel transitively, run license and vulnerability scanning across that chain rather than just the top-level package.

Sequencing (if we proceed).

1. Confirm Nova tier and version, and confirm we are willing to own a Vue component if needed.
2. Spike on a staging dashboard with one card and hardcoded slides; verify build and render on our Nova version.
3. Decide: consume as-is only if it is actively maintained and version-compatible; otherwise vendor the small codebase into our own app's Nova cards, keeping MIT attribution.
4. If forking: drop the Composer dependency, own the component in-repo, replace the carousel with a maintained Vue 3 slider (Swiper/Embla), add keyboard controls and reduced-motion handling.
5. Roll out to one admin dashboard, collect feedback, then decide whether to standardize.

Verdict. At 9 stars and 0 dependents, the default is fork-or-rebuild — a comparable card is on the order of one hundred lines — not "take a dependency."

Operational Impact

Maintenance. The dominant cost, and it is disproportionate to the feature. The upstream project shows essentially no maintenance signal, so we inherit the obligation to fix this card on every Nova upgrade — and Nova upgrades are effectively forced by Laravel and PHP upgrades. We would be adopting a cosmetic widget and a recurring upgrade chore.

Support. None beyond GitHub issues: no SLA, no security advisory channel, no downstream community to lean on. The support burden lands on whoever owns the admin dashboard — typically a small team with limited front-end capacity.

Scaling. Runtime cost is negligible (a few DOM nodes and one bundled JS file per dashboard load). The scaling risk is organizational: each additional Nova card sourced from an unmaintained project compounds upgrade exposure. The only genuine performance concern is media weight — large slide images on a dashboard — mitigated by lazy loading and serving through existing CDN/asset paths.

Failure modes.

• Blank card after a Nova or PHP upgrade (asset 404 or Vue major mismatch) with no server-side error surfaced.
• A throw-on-mount in the component degrading the broader dashboard JS bundle.
• Stored XSS through unescaped slide content.
• Accessibility audit findings requiring rework of a "finished" widget.
• Upstream abandonment or repo removal — bounded by the MIT license and the ability to vendor.

Ramp-up. Low technical ramp-up: Nova cards are a documented, well-trodden pattern and the codebase is tiny. The real ramp-up is onboarding an internal owner after the original maintainer goes quiet. Budget one to two days for a front-end-capable developer to fork the card, swap in a maintained Vue 3 carousel, and add a basic render test — almost certainly cheaper over twelve months than depending on this package. Given the low opportunity score, this should be scheduled as discretionary admin polish, not a roadmap item.