Charts Laravel Package

Technical Evaluation

Architecture fit. corals/charts is a server-side, Laravel-native charting package in the fluent-builder category: PHP code describes a chart (type, labels, datasets, options), and the package emits a chart specification plus the Blade view/JS needed to render it. Architecturally this is a thin presentation-layer dependency — no persistence, no queue workers, no auth surface, no migrations. That makes it cheap to adopt and cheap to remove, but it also means the package is competing with "write 150 lines of config array ourselves," which is the real baseline to beat.

Fit is good only under specific conditions: Blade-rendered dashboards, low JS tooling appetite, a small number of chart types. If the product is API-first, Inertia/React/Vue, or already has a charting component library on the front end, this package adds a server-side abstraction over a client-side concern and will likely be bypassed by the first engineer who needs a custom tooltip.

Integration feasibility. Mechanically straightforward: Composer install, service-provider auto-discovery, optionally publish config/views, render in a Blade template. MIT license removes legal friction. The uncertainty is compatibility, not effort — the last release is 2022-08-08, which places it in the Laravel 8/9 era. Laravel 10/11/12 and PHP 8.2+ support must be verified empirically, not assumed, because the package's composer.json constraints may hard-block install even if the code works fine.

Technical risk. This is the dominant concern and it is a governance risk, not an engineering one:

• Abandonment. No release in roughly three and a half years, zero stars, zero dependents. There is no upstream to fix a bug, patch a CVE, or accept a PR.
• No ecosystem signal. Zero dependents means no field-testing, no Stack Overflow corpus, no "someone else hit this." Every defect is ours to discover.
• Bus factor of one, with no observable CI/test posture to tell us how much of the surface is actually covered.
• Supply-chain/asset risk. Verify whether it shells out to a CDN at render time (availability and version-drift risk) or publishes bundled JS.
• Injection risk. Chart labels and datasets are user-influenced data crossing into JavaScript. If the escaping path is naive string interpolation, that is a stored-XSS vector we would own forever.

None of these are disqualifying for a low-stakes internal dashboard. All of them are disqualifying for a customer-facing, regulated, or long-lived surface without an internal fork.

Key questions to answer before committing:

1. Does it install and render on our current Laravel and PHP versions, cleanly, with no --ignore-platform-reqs?
2. Which charting library does it wrap, and under what license? Does it pin a version?
3. Does it render via CDN <script> tags, published assets, or npm/Vite?
4. How are labels and dataset values escaped on the way into JS?
5. Is there any test suite, and does it pass locally?
6. Can we consume only the chart-spec builder and supply our own Blade/JS rendering?
7. Is the vendor reachable, and would they accept a security patch?

Integration Approach

Stack fit. Adopt if the stack is Laravel + Blade + minimal JS and the charts are operational dashboards, admin reporting, or internal metrics. Reject if charts are a core product surface, if the front end is a SPA consuming JSON, or if we already own a design-system chart component — in that case the package's rendered markup will fight our design system rather than compose with it.

Migration path. Given abandonment, the defensible path is vendoring, not depending. Concretely, in preference order:

1. Fork into a private namespace (e.g. App\Support\Charts or an internal acme/charts Composer package). Retains the fluent API, removes Packagist as a runtime dependency, and lets us patch compatibility ourselves.
2. Vendor-copy the handful of source files into the app and delete the service provider, if the surface turns out to be small.
3. Reimplement if the spike shows the package is a 200-line config builder plus a Blade partial. At that size, ownership cost of a fork exceeds ownership cost of a rewrite, and a rewrite carries no license or attribution overhead.
4. Depend directly on Packagist only for a throwaway internal tool with a defined sunset.

Whatever the path, wrap it behind our own ChartBuilder interface so call sites never touch the vendor API. That contains the blast radius to one file when we inevitably replace it.

Compatibility. Pin explicit PHP/Laravel constraints in our own fork's composer.json rather than inheriting stale ones. Run composer why-not during evaluation to surface conflicts early. Confirm asset publishing works under our Vite pipeline, or explicitly decide to load the charting library from npm ourselves and let the package emit only config.

Sequencing.

1. Spike, half a day. One engineer, one representative chart, on current Laravel. Record install friction, rendered output, and escaping behavior.
2. Security read. Audit the label/dataset path for escaping. This is a gate, not a task.
3. Decide adopt / fork / rewrite / reject against a written criterion: does the package save more than the ~2 days a rewrite would cost?
4. Contain. If adopted, land the wrapper interface and one integration test before the second chart ships.
5. Migrate incrementally. Charts are leaf nodes — no data migration, no cutover risk, easy to convert screen by screen or abandon mid-way.

Operational Impact

Maintenance. Effectively zero upstream maintenance and non-zero internal maintenance. Realistic budget: 1–2 engineer-days per year in steady state, plus a spike each time we cross a Laravel major version. The cost is not patching; it is the recurring "is this still safe?" review that every unmaintained dependency imposes on the team.

Support. There is no vendor support and no community to escalate to. Ownership must be explicit: one named engineer, an ADR recording why the package was chosen, and a note in the dependency inventory flagging it as unmaintained. Without that, the package silently becomes nobody's problem until it breaks a release.

Scaling. Server-side cost is negligible — the package builds an array and renders a template; it does not compute at request time. The scaling risk is payload size, not CPU: large series get serialized inline into the HTML, inflating response size and time-to-interactive. Cap series count and data points at the wrapper layer and aggregate server-side rather than shipping 50k points to the browser. Concurrency is a non-issue.

Failure modes, ranked by likelihood:

• Laravel major upgrade breaks the service provider or view bindings. Near-certain eventually; no upstream fix will arrive. Mitigation: the fork, plus the integration test that fails loudly.
• Escaping defect becomes stored XSS. Low probability, high severity, and permanently unpatched if we depend on Packagist. Mitigation: audit at evaluation time; sanitize at the wrapper.
• CDN or pinned JS version disappears or drifts. Medium probability if rendering is CDN-based; fails silently as "charts just stopped drawing." Mitigation: self-host the JS via npm/Vite.
• Silent visual regression after a front-end or CSP change. No upstream tests will catch it. Mitigation: a single visual smoke test is worth more than the package's entire test suite.
• Dependency-resolution deadlock on a future PHP bump. Annoying, recoverable, and the moment the fork pays for itself.

Ramp-up. Low — hours, not days. A mid-level Laravel developer reads the fluent API and ships a chart the same afternoon; the concept count is small (chart type, labels, datasets, options). The real onboarding cost is not learning the package, it is teaching the team which layer owns chart configuration. Without the wrapper interface, chart-building logic will scatter across controllers and Blade templates, and the eventual migration becomes a codebase-wide search rather than a one-file swap. Document the intended usage pattern alongside the ADR.

Bottom line for a TPM. Low integration cost, low architectural risk, high ownership risk, negligible community. The opportunity score in the mid-40s reads correctly: cheap to try, but only justified for internal or low-stakes visualizations where a fork is acceptable and a rewrite is a viable fallback. Do not put it on a customer-facing surface or a multi-year roadmap without vendoring it first.