Nova Chartjs Laravel Package

Product Decisions This Supports

• Build vs. buy for internal reporting. This package replaces a bespoke Nova field — roughly 200–400 lines of Vue plus asset registration — with composer require and a PHP closure. The saving is bounded (hours to a day, not a sprint), but it is real for a team without a front-end toolchain, and it is the cheapest way to test whether internal reporting demand is durable before funding it.
• Where the "insights" surface lives. It lets you embed a record-scoped chart inside the admin panel the team already opens daily, shipping a v1 metrics view without triggering a BI procurement cycle (Metabase, Looker, Power BI). Defer that spend until usage proves the demand is recurring rather than a one-off ask.
• Scope boundaries on analytics. This is a Nova Field, not a dashboard primitive. It renders a fixed, server-computed series on a resource detail view. Treat that constraint as a feature: it forces per-record or per-metric charts and stops an internal admin tool from quietly growing into an analytics product nobody scoped. Nova's native Value/Trend/Partition metrics remain the correct surface for dashboards.
• Evidence-driven prioritization. Activation, usage, revenue, and per-account trends land in front of the team, CS, and support without a new login or a data-export ritual. Shorter loop from data to decision, and fewer ad-hoc "can you pull this?" requests routed to engineering.
• Total cost of ownership math. Free and MIT, but gated on a paid Nova license — already sunk if you run Nova, disqualifying if you don't. No new runtime, no pipeline, no vendor contract. The real TCO is maintenance (estimate 2–5 engineer-days/year, concentrated around Nova majors), not license.
• Vendor-risk calibration. Blast radius is contained. Chart.js does the rendering; this is a thin adapter over it. Chart configs are portable, so abandoning the package means rewriting field definitions, not re-platforming analytics. That asymmetry is what makes a low-maintenance dependency acceptable here.
• Expectation-setting on the pitch. Marketing copy says "dashboards and cards," but the implementation is a detail-view field. Resolve that discrepancy before committing: if the requirement is a dashboard, the answer is native Nova metrics, not this package.

When to Consider This Package

Adopt when:

• You already run Laravel Nova at the major version the package supports — a hard gate, verifiable in about an hour with composer why-not before any code is written.
• The audience is internal — ops, support, CS, leadership — where a stale dependency is an annoyance rather than an outage.
• Requirements are simple: line, bar, pie, or doughnut over a pre-aggregated series of a few hundred points, scoped to a single record.
• The request is "show me this account's trend on its detail page," not "let me slice and filter." Static, server-computed charts are the whole product.
• You are willing to treat it as vendored code: wrap it in an internal factory, keep series logic in testable model or service methods, and budget a small annual maintenance allowance around Nova upgrades.
• You need a time-boxed pilot to validate reporting demand before proposing a BI tool. Half a day to first chart is a legitimate experiment cost.

Look elsewhere when:

• The ask is a dashboard — multiple charts, cross-record comparison, a landing view. Use Nova's native metrics, or buy BI. This field will not get you there without custom work that exceeds the package's value.
• Stakeholders want interactivity: date-range pickers, drill-down, async refresh, export. The package has no refresh path — every render is one server-side computation — and adding these is a product project, not a field option.
• The chart is customer-facing or exposed to untrusted labels. HTML tooltips plus user-supplied labels is an XSS surface; canvas-only with trusted labels is fine.
• You are on a Nova major the package has not shipped for. Release 2.0.0 (March 2023) is the Nova 4 release; nothing since. Nova 5 support is unverified — fork on day one or don't adopt.
• Data volume is large or the aggregate is expensive. One query per chart per page load is fine for an internal tool at low concurrency; six charts on a wide table is not. Downsampling must happen in SQL before it reaches the closure.
• You need a maintained dependency with a support contract or an active user base. 51 stars and zero dependents means you are the only one exercising your edge cases, and there is nobody to file the bug report with.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible bet. It puts trend and mix charts on the record pages the team already uses, so activation, usage, and revenue questions get answered without a new tool, a new login, or a data-export request to engineering. Cost is zero license on top of the Nova seat we already pay for; the real cost is a few engineer-days a year, mostly around Nova upgrades. It is deliberately not a BI replacement — it is the cheap test of whether reporting demand is recurring, and it tells us whether to fund the real thing later. If it disappoints, we walk away having rewritten a handful of field definitions, not a platform.

To engineering: It is a thin Nova field wrapping Chart.js — no service provider, no migrations, no npm step, prebuilt assets in the package. The learning surface is Chart.js option syntax, not this package; the source is readable in an afternoon. Two asks before we commit: verify Nova compatibility with composer why-not as a gate, and treat it as vendored rather than installed — wrap field creation in our own factory, keep aggregation in testable series methods with gap backfill and int casts, scope to detail views to avoid a self-inflicted N+1, and keep one canary resource to click after every Nova upgrade. That wrapper is what turns a future migration into a two-day job instead of a two-week one.

To the requesting team: We can show you the trend on the account page — the monthly line, the status mix — inside the tool you already open. What we are not committing to yet is a filterable dashboard, date pickers, exports, or drill-down. Those are a different product decision with a different price tag, and we would rather earn that spend with evidence from this first version than guess at it upfront.