Charts Laravel Package

Technical Evaluation

Architecture fit. This is a presentation-layer convenience for internal admin screens, not a platform component. Its value is conditional on one thing: that we run (or are about to commit to) the Orchid Platform admin panel. Outside Orchid — Filament, Nova, a bespoke Blade app — the fit is effectively zero, and adopting it would be an implicit architectural vote for Orchid rather than a neutral tooling choice. Even inside Orchid, what we are buying is a reusable chart-as-a-class wrapper over data we already have as Eloquent results or arrays. That is roughly one to three developer-days of work we would otherwise write ourselves, so the ceiling on adoption effort is low by construction.

The identity problem is the first technical risk, and it precedes all others. Three sources disagree: the package metadata describes "server-side SVG charts, zero JavaScript runtime"; description.md describes interactive Chart.js visualizations; the v0.0.10 release notes describe a Vitest/ESLint/Vite toolchain and state the published package has no runtime dependencies — the profile of a frontend package. These lead to different ownership (Composer vs. resources/js), different failure modes (asset loading vs. render internals), and different migration plans. A TPM cannot sequence work on this until it is resolved. Fifteen minutes of triage — inspect composer.json, inspect src/, check for an auto-discovered service provider, render one hardcoded chart — settles it. Until then, no roadmap item should depend on this package.

Integration feasibility. Low-to-moderate, provided the Orchid precondition holds. The install path is a standard composer require plus a provider registration or publish step, and the first use case is deliberately small: one real metric on one real screen. The real cost is not installation, it is the conventions we layer on top — a base chart class, a semantic palette, a caching rule, a timezone boundary. Those are ours to write regardless of which library we use, and they are what makes the dependency cheap to replace later.

Technical risk.

• Pre-1.0, v0.0.10, pin exactly. The release notes describe adapting tooltip builder option handling to an ESLint major "while preserving callback and visibility behavior" — the fact that it needed stating is the tell. Behavioral drift in tooltip callbacks is user-visible and silent, and a smoke test that only checks the chart draws will not catch it.
• Zero stars, zero dependents. No ecosystem, no Stack Overflow answers, no third-party examples. Source-reading is the documentation, which makes knowledge concentration a real operational risk rather than a theoretical one.
• The braces advisory (GHSA-vfj7-8cjw-p6xm) rides in transitively via Stylelint. It is dev-only and the production audit is clean, but a blanket Dependabot suppression is how a real finding gets missed later. Scope the exception, set a review date.
• Chart-level correctness risks that will reach users: timezone/date-bucketing off-by-ones between DB session time and config('app.timezone'), blank canvases on empty datasets, and unbounded pluck() pulling entire tables into PHP on a page that loads on every admin view.

Key questions to close before commitment.

1. Is this a Composer library or an npm build-time asset? Who owns it in each case?
2. Which provider registration path applies — auto-discovered or manual config/app.php?
3. Which chart types actually exist in src/, versus what the prose promises?
4. What Orchid / Laravel / PHP versions are supported, and is there any compatibility matrix at all?
5. If the Chart.js reading holds, does the package ship its own Chart.js or expect ours in the bundle?
6. Who is the named internal owner, and what is the investment ceiling in engineer-days?
7. What is our exit price — the estimate to hand-roll the equivalent wrapper if we abandon this?

Integration Approach

Stack fit. Laravel + Orchid only. If we are not on Orchid, this assessment ends here; do not adopt it as a hedge for a future admin decision. If we are on Filament or Nova, the correct action is to write the wrapper ourselves against Chart.js, and the one-to-three-day estimate from the evaluation is the number to plan against.

Migration path. Spike first, integrate second. Run the identity triage in a throwaway branch, then build exactly one chart — "orders per day, last 30 days" — on the screen where a numeric list would otherwise live. That single artifact exercises the whole chain (query → chart class → layout registration → render) and gives us something concrete to debug against. If it renders, we standardize; if it fights us, we stop and take the build-ourselves path while the sunk cost is still measured in hours.

Two conventions carry the migration and should be established on that first chart, not retrofitted:

• Our own base chart class. Subclass the vendor type, keep the aggregation and option-building in our code, and reach for package rendering internals last. At v0.0.10 those internals are actively moving, and anything monkey-patched there is one version bump from breaking. Isolating in our base class makes the vendor upgrade a one-file change — which is also what makes the exit cheap.
• A single semantic palette. Revenue green, refunds amber, errors red — defined once, pulled by every chart class. Eight charts with eight ad-hoc color arrays is what the dashboard looks like in month two, and inconsistent meaning on an ops screen is worse than inconsistent aesthetics.

Compatibility. Pin "orchid/charts": "0.0.10" exactly — not ^0.0.10, not *. Verify the Orchid, Laravel, and PHP versions the package actually supports against ours before writing anything. If the frontend reading holds, also verify the Vite/Node toolchain compatibility and confirm whether Chart.js comes from the package or from our bundle. Resolve this at install time; a chart that renders axes but no data is usually the charting library loaded twice or not at all, and that diagnosis costs an afternoon if we discover it in a screen review instead of in a spike.

Sequencing.

1. Identity triage (Composer vs. npm vs. neither) — hours, blocks everything.
2. Single-chart spike on one real screen — one to two days including source-reading.
3. Go/no-go: adopt, or build a thin wrapper ourselves. Record the decision and the exit price.
4. If adopt: codify base class, palette, cache-key convention, timezone boundary, empty-state handling.
5. Roll to three to five read-only KPI screens, no more.
6. Review at that point against a real reporting request — drilldown, export, alerting, cross-source joins are the signals to move to a real BI tool, not to extend this.

What we are explicitly not doing. Not adopting it customer-facing, not adopting it as a hedge for an undecided admin stack, and not adopting it to avoid a day of wrapper work only to spend a week bending it to requirements it was never generic enough to meet.

Operational Impact

Maintenance. Assign a named owner and a low investment ceiling from day one. This is an internal-tooling dependency, never something a customer-facing commitment rests on. Because the source is the documentation, require a comment block in each chart class recording the API shape as verified — it is the only onboarding material the team will have, and it is what makes the second developer productive without re-reading src/. Budget for pre-1.0 upgrade work as a recurring line item rather than a surprise; a dependency that shipped tooltip-callback fixes under an ESLint major will keep moving.

Support. There is no community to escalate to: zero stars, zero dependents, no third-party examples or answers. The failure mode this creates is not "we can't fix it," it is "one person knows how it works." Mitigate by having at least two engineers touch the integration during the spike and rollout, and by keeping the vendor coupling behind our own base class so the fallback is a known quantity.

Scaling. Two different cost profiles depending on which reading of the package is true, and both are manageable if we set the rules early:

• Server-side rendering: cost is SQL cost. Aggregate in SQL, never hydrate rows to count them, never pluck() an unbounded relation without limit(). Put the aggregation in a cache keyed by the query window — chart.orders.{from}.{to} — never by request()->fullUrl(), which explodes the key space. Invalidate on write, or accept a five-minute staleness on an analytics view.
• Client-side Chart.js: add per-page payload size and bundle weight to that model. Dashboards are read-heavy and often loaded on every admin page view, so a chart that quietly pulls a large table is the thing that makes the admin feel slow, and nobody profiles it because "it's just a chart."

The genuine scaling risk is organizational, not technical: charts spreading from a handful of KPI panels to a de-facto analytics surface that this dependency cannot carry. Draw that line in the roadmap now.

Failure modes to plan for.

Ramp-up. Low for any Laravel developer — the fluent API is not the friction. Half a day to productive on the existing chart classes, plus the verified-API notes as the entry point. The cost that does not compress is source-reading during the spike, which is why the spike is scheduled first and time-boxed rather than absorbed into a feature estimate.