matheusmarnt/livecharts
LiveCharts is a reactive chart abstraction for Laravel that unifies ApexCharts and Chart.js behind one fluent PHP API. Define 18 chart types in PHP, render with a single Livewire component, and update them reactively from application state—no JavaScript boilerplate.
Architecture fit. LiveCharts is a Laravel-native abstraction over ApexCharts and Chart.js delivered through a single Livewire component. It fits best in Livewire-first Blade applications—internal dashboards, admin panels, reporting screens, and SaaS back offices—where chart definitions can live in PHP and update from Livewire state. It is a poor fit for API-only services, Inertia/React/Vue SPAs, or teams standardizing on a JavaScript charting layer, because the package’s value is specifically the PHP fluent API plus Livewire hydration. The EngineAdapter contract and LiveCharts::registerEngine() provide a reasonable escape hatch for custom engines, but the core coupling to Livewire remains.
Integration feasibility. The install path is straightforward: composer require, php artisan livecharts:install, publish config and assets, add @liveChartsScripts before @livewireScripts, then render <livewire:livecharts :chart="$chart" />. Class-based charts and make:chart support reusable, testable chart definitions. The main integration constraints are asset ordering, local-vs-CDN asset strategy, Tailwind v4 alignment for the theme-token API, and verification that required chart types render equivalently on the chosen engine. The package’s CI matrix—PHP 8.2–8.5, Laravel 11/12/13, Livewire 3/4, PHPStan level 8, 301 tests—is a positive quality signal.
Technical risk. The dominant risk is adoption and bus factor: 5 stars, 0 dependents, and a single maintainer. The package appears actively maintained with changelogs through 1.18.0 and strong test discipline, but it is pre-2.0 and has visible API expansion across recent minor releases. That implies upgrade churn and limited production evidence. Secondary risks include engine parity across 18 chart types, client-side rendering failures that server monitoring will not catch, CSP/CDN asset concerns, Livewire-only rendering constraints, large-payload performance, and polling/broadcasting load. MIT licensing gives a fork option, but forking a chart abstraction is non-trivial.
Key questions.
Stack fit. High fit for Laravel 10–13 + Livewire 3/4 + Blade + Tailwind applications. Medium fit for Laravel apps with mixed frontend stacks where charts can be isolated as Livewire islands. Low fit for Inertia/React/Vue or non-Livewire frontends. The package should be treated as a presentation-layer dependency, not a data or analytics platform.
Migration path. Start with a time-boxed spike on one low-risk dashboard. Install in a non-production environment, pin an exact Composer version, choose local or both asset mode, and verify the script directive ordering in the base layout. Build one chart class under app/Charts and wrap package calls behind an internal chart factory or facade so future engine or package changes do not leak into views. For existing ApexCharts/Chart.js code, migrate one chart at a time and compare rendered output, interactions, and payloads against the existing implementation.
Compatibility. Confirm PHP 8.2+, Laravel and Livewire versions, Tailwind version, CSP rules, and deployment asset publication. The default both asset mode requires public/vendor/livecharts/js to exist after deployment; otherwise use cdn mode or add vendor:publish --tag=livecharts-assets --force to the release pipeline. Validate wire:navigate behavior and Livewire hydration for the target version. If Tailwind v4 is not in use, rely on explicit colors rather than the TwColor/TwPalette theme API.
Sequencing.
Maintenance. Expect a small-team dependency with a single primary maintainer. Pin versions, monitor releases and changelogs, and assign an internal owner for upgrades. Budget for periodic compatibility reviews because the package is still expanding its API surface. The MIT license provides a fork path, but maintaining a fork of a Livewire/JS chart abstraction would be costly and should be a contingency, not a plan.
Support. There is no commercial support model. Escalation will be GitHub issues, source inspection, and internal patching. Document known constraints—asset ordering, supported engine/type combinations, and browser test procedures—so support does not depend on one engineer’s knowledge.
Scaling. Rendering is client-side, so server cost is driven by Livewire payload size and update frequency rather than chart rendering itself. Aggregate data server-side, cap dataset sizes, cache expensive queries, and avoid per-user polling storms. For high-frequency updates, prefer broadcasting over polling and stagger refresh intervals. Local asset delivery is preferable for availability and CSP control; CDN fallback introduces an external dependency.
Failure modes. Common failure modes include blank charts from missing published assets or incorrect @liveChartsScripts placement, CSP blocking engine scripts, CDN outages, unsupported chart-type/engine combinations, empty or malformed datasets, Livewire hydration mismatches, theme observer failures, and excessive polling or broadcast load. Server-side exceptions such as InvalidChartType, EmptyDataset, and DataShapeMismatch should be caught and surfaced as safe UI fallbacks. Because rendering failures happen in the browser, add frontend error telemetry and a basic “chart unavailable” state.
Ramp-up. Low for Laravel/Livewire developers: the fluent API is readable, class-based charts are familiar, and livecharts:preview plus the docs site reduce discovery time. A mid-level Laravel developer should ship a first chart in one to two days. Team-wide standardization—conventions, testing, asset policy, and engine selection—is a one-to-two-sprint effort. The TPM should plan enablement, a pinned-version policy, and a pilot exit review before broader rollout.
How can I help you explore Laravel packages today?