Charts Laravel Package

Product Decisions This Supports

• "Do we need a BI tool?" — answered cheaply. This package turns Eloquent results and plain arrays into line/bar/pie/doughnut/radar views inside the Orchid admin panel. For internal read-only KPI panels, trend lines, and category breakdowns, it is a viable substitute for a Metabase/Looker seat or a bespoke Chart.js build. Frame every internal-dashboard request against that baseline first; escalate to BI procurement only when the request genuinely needs drilldown, export, alerting, or cross-source joins.
• Roadmap sequencing for reporting. It creates a credible "lite tier": ship simple read-only metrics in the admin now, defer an analytics platform until a real request justifies it. This lets us say "not yet" to BI tooling without saying "no" to the stakeholder.
• Admin stack standardization. The package only pays off inside Orchid, so it is a small but real input to the larger build-vs-buy decision on the admin panel (Orchid vs. Filament/Nova/bespoke Blade). Adopting it is a mild commitment to Orchid; declining it does not force a move.
• Build-vs-buy on chart plumbing. A reusable chart-as-a-class abstraction is roughly one to three developer-days of wrapper work we would otherwise write against Chart.js. The package is a win only if that abstraction is genuinely generic — do not adopt it to save a day and then spend a week bending it.
• Ownership and investment ceiling. 0 stars, 0 dependents, v0.0.10. This is a convenience layer, not a platform bet. Scope it as internal-tooling with a named owner, a pinned version, and a low investment ceiling — never as a dependency a customer-facing commitment rests on.
• A process finding, not just a technical one. The package is presented as a Laravel/PHP Composer package, but the summary claims "PHP-first server-side SVG charts, zero JavaScript runtime," the description claims interactive Chart.js, and the v0.0.10 release notes describe a Node/Vitest/ESLint/Vite toolchain with "no runtime dependencies." Before a roadmap item depends on it, we must know whether we are adding a Composer dependency, an npm build-time asset, or nothing at all. Our intake pipeline let three contradictory signals through — worth fixing regardless of what we decide here.

When to Consider This Package

Consider it when all of these hold:

• We are already committed to the Orchid Platform for internal admin screens. Outside Orchid the value is close to zero.
• The need is read-only metric visualization — a handful of KPI panels, trend lines, category breakdowns — not an analytical product with filters, exports, or ad-hoc querying.
• The data is already reachable as Eloquent results or arrays in the Laravel app. No new pipeline, warehouse, or ETL.
• The surface is internal and authenticated: charts are for staff, not customers, and never embedded in anything a customer-facing SLA rests on.
• Engineering has done the fifteen-minute identity triage first — confirm whether the artifact is a Composer library (composer.json requiring laravel/framework/orchid/platform) or a frontend asset. Plan for SVG and get Chart.js and assets silently fail to load; plan for Chart.js and get SVG and we hunt for a config option that does not exist.
• We accept a hard version pin (0.0.10, not ^0.0.10) and a review date. Pre-1.0 with a single-digit star count means the source and tests are the documentation; budget for one engineer to read them and leave notes.

Look elsewhere when any of these are true:

• The admin panel is Filament, Nova, or bespoke Blade. The package is Orchid-specific; do not restructure the admin to use it.
• The requirement includes self-serve exploration, exports, scheduled reports, alerting, or joins across sources. That is BI-tool territory, and this package will accrete into a bad one.
• The charts are customer-facing or part of a contractual deliverable. Zero dependents means no ecosystem support, no Stack Overflow answers, and no third-party examples — support burden lands entirely on us.
• We cannot yet say whether this is PHP or JS. Do not start a roadmap item while that is unresolved; hand ownership to whoever owns resources/js if it turns out to be frontend-only.
• The real ask is "one number on a screen." A stat panel or a table is cheaper, testable, and has no dependency.

Budget the known carry costs. No runtime dependencies means whatever renders client-side is ours to bundle — a chart that draws axes but no data usually means the charting library loaded twice or not at all. Timezone and date-bucketing disagreements between DB session time and config('app.timezone') will produce off-by-one charts that erode operator trust in the numbers. Empty datasets often render as a blank canvas rather than "no data." Dev-only advisories (the braces GHSA via Stylelint) should get a scoped, dated audit exception rather than repeatedly failing CI — but keep the exception scoped.

How to Pitch It (Stakeholders)

To executives: We can put real operational metrics in front of staff — orders per day, revenue trend, error counts — inside the admin panel we already run, for roughly one to three developer-days of integration instead of a BI platform contract. It is a scoped internal-tooling dependency at v0.0.10 with no production dependencies and a clean production audit; we pin the version, name an owner, and set a review date. It buys us the ability to say "not yet" to BI procurement without saying "no" to the stakeholder, and it defers the real analytics decision until a request actually needs drilldown, export, or alerting.

To engineering: Charts become named, testable, reusable classes rather than inline arrays in a layout method — one class per business metric, taking its query window through the constructor, so we can unit-test the payload against a fixture instead of eyeballing pixels. Aggregate in SQL, cache the payload (not the view), standardize a semantic palette once, and handle the empty dataset explicitly. Resolve the PHP-vs-JS identity question before writing a single chart class: check composer.json and src/ first, render one hardcoded chart on one real screen, and only then build conventions. Pin exactly "orchid/charts": "0.0.10"; the release notes describe tooltip option-handling being adapted for an ESLint major with behavior merely "preserved" — silent, user-visible drift we would not catch in a smoke test.

To the platform/architecture owner: This is a small, reversible bet, and it doubles as a signal about our admin stack direction. Adopting it is a mild commitment to Orchid; declining it commits us to nothing. The one thing we should not do is let it in unresolved — the metadata says server-side SVG, the description says Chart.js, and the changelog says Node toolchain. Get a clear answer, then decide.