Nova Apex Chart Laravel Package

Technical Evaluation

Architecture fit. digital-creative/nova-apex-chart is a thin Nova add-on: a Composer package that registers a service provider, ships a PHP component class extending Nova's field/card contract, and hands an ApexCharts options payload to a compiled Vue component mounted through Nova's asset pipeline. That is a good architectural fit only if we are on Nova 2.x/3.x, which is the 2020-era surface this was built against. Nova 4 moved to Vue 3/Inertia and Nova 5 continued that line; a component last released in July 2020 almost certainly will not mount without modification. The package adds no server-side rendering, no data layer, and no aggregation — it is purely presentation, so it does not conflict with our application architecture, but it also provides nothing we could not assemble ourselves in roughly a day.

Integration feasibility. Mechanically trivial: composer require, publish assets, register the component, feed it series/options. The gate is not effort, it is version compatibility. With 7 stars and zero dependents there is no installed base generating compatibility evidence, no one filing issues against Nova 4/5, and no CI matrix confirming PHP 8.2/8.3 or Laravel 10/11 support. Feasibility should be treated as unproven until we run a spike.

Technical risk. High, concentrated in four places:

• Abandonment. Single-maintainer package, no release in ~5 years, no security triage. The opportunity score (6.06) reflects unmet need in the ecosystem, not package quality.
• Host-framework coupling. Nova is closed source with a paid license and a history of breaking add-ons on major releases. We cannot read the contract we are depending on.
• Stale JS supply chain. The bundled ApexCharts build is 2020 vintage and unpinned. This needs a software-composition scan before it touches an admin surface, and ApexCharts formatters/tooltips render values into the DOM — if series labels or options derive from user-controlled data, we inherit an XSS path inside an authenticated panel.
• No semver gravity. With no downstream consumers, breaking changes ship silently or not at all.

Key questions.

1. Which Nova major are we on today, and what is the committed upgrade cadence to Nova 5/6?
2. Do we need interactive charts, or are Nova's native Trend/Value/Partition metrics sufficient for the dashboards in scope?
3. Who owns the fork, and is that person Vue-3-fluent?
4. What are peak series cardinality and refresh cadence? Client-side rendering cost is ours to manage.
5. Is any chart data derived from tenant- or user-supplied strings?
6. Do we need charts in exports/PDFs, which would require a headless-browser or SVG-snapshot path the package does not provide?

Integration Approach

Stack fit. Laravel + Nova, Composer-distributed, assets published into public/vendor. It assumes Nova's own asset compilation conventions; if we run a custom nova:publish or Vite-based build step, we should expect to reconcile two asset pipelines. ApexCharts itself is a sound, widely used library — the risk is the wrapper, not the renderer.

Migration path. Do not consume this as an upstream dependency. MIT license permits the pragmatic route: fork into our org, keep the PHP component class (it is small and mostly a config passthrough), and replace the bundled ApexCharts build with a current pinned version. That converts an unmaintained dependency into a ~200-line vendored component we fully control. The alternative — build the field from scratch against Nova's documented custom-field API — is a comparable amount of work and gives a cleaner audit trail.

Compatibility. Target Laravel 10/11, PHP 8.2+, Nova 4/5. The Vue 2 → Vue 3 migration of the component is the single largest work item; if we cannot staff it, we must scope the package to Nova 3 only and attach a hard decommission date rather than let it drift. Verify against Nova's dark mode and responsive breakpoints, which the 2020 build predates.

Sequencing.

1. Spike (2–3 days): stand up a sandbox Nova instance, attempt to render three representative charts, log every failure.
2. Decide: fork-and-modernize vs. native Nova metrics vs. build-in-house. Do not proceed to step 3 without this decision documented.
3. Fork and harden: bump ApexCharts, add a CI matrix (PHP × Laravel × Nova), add an SCA job, tag 1.0.0-internal.
4. Pilot: one internal dashboard, one team, two weeks.
5. Generalize: publish as an internal package with a documented options schema.
6. Calendar a re-evaluation before any Nova major upgrade — make this a recurring ticket, not a hope.

Operational Impact

Maintenance. We become the maintainer. Budget roughly 1–2 engineer-days per quarter for dependency bumps and Nova compatibility patches, plus a mandatory 3–5 day re-evaluation on every Nova major. Automate with Renovate/Dependabot on the fork and a CI matrix so breakage surfaces in a PR rather than in a customer's dashboard.

Support. No upstream. Issues on the source repo are effectively unread; there are no security advisories and no one to escalate to. Internally we must designate an owner and a fallback, and document the component in our own runbook. For an admin-panel visualization this is tolerable; it would not be for anything on the customer-facing path.

Scaling. All rendering cost is client-side. Server load is negligible; browser load is not. Ten chart cards on one Nova dashboard multiply the ApexCharts payload and the render pass. Mitigate by capping series count and point count, downsampling server-side before handing data to the component, and lazy-loading cards below the fold. Treat the options payload as a contract — large series arrays serialized into the page will show up as slow TTFB on the dashboard route.

Failure modes.

• Silent blank card — the most likely failure: assets not republished, or a Vue mount error swallowed by the console. Needs a health check or a visible error state, not an empty div.
• Nova upgrade breakage — component fails to mount after a Nova minor bump; no upstream fix will arrive.
• Stale dependency exposure — an ApexCharts vulnerability with no patched release from the package.
• Injection — user-controlled strings in labels/tooltips with formatters enabled.
• CSP friction — ApexCharts' styling approach can conflict with a strict Content-Security-Policy; validate against our headers early, not at launch.

Ramp-up. Low for any developer already fluent in Nova custom fields — the API is a config passthrough and the PHP side is a few dozen lines. The real ramp is the Vue 2/3 gap and Nova's asset pipeline, which is where a mid-level developer will lose time. Plan for one engineer to own it end-to-end rather than distributing knowledge across the team; with a package this small, single-owner is cheaper than documentation overhead.

Verdict. Adopt only as a forked, internally owned component with a pinned ApexCharts build, or skip it entirely in favor of Nova's native metrics for simple cases. The package is a reasonable starting shape and a poor long-term dependency.