Larapex Charts Laravel Package

Product Decisions This Supports

• Dashboard and reporting features in Laravel admin panels. Larapex-charts is a thin, opinionated server-side wrapper that turns PHP data into ApexCharts configuration and renders it in Blade. This makes it the lowest-friction option for "show me a line/bar/donut chart of this Eloquent query" requirements that appear in almost every internal tool, SaaS admin area, or customer-facing analytics screen.
• Build vs. buy at the charting layer. It supports build on the presentation layer (you own the Blade views and option arrays) while relying on the maintained upstream ApexCharts JS library for interactivity, tooltips, zoom, and responsiveness. The decision it removes is "do we hand-roll chart JSON and a JS bootstrap in every project?" — the answer becomes no.
• Scope boundary for analytics roadmap. This package is a rendering tool, not an analytics platform. It does not do aggregation, caching, scheduled rollups, cohorting, or export. It cleanly supports a decision to ship "charts of data we already query" now, and to defer/decline "self-serve analytics, saved reports, CSV/PDF export, alerting" until a real BI tool is justified.
• Vendor and maintenance risk posture. The v10.1.0 release is entirely engineering-hygiene work: Rector for automated refactoring, PHPStan introduced and ratcheted from level 1 to level 8, PHPStan wired into the CI workflow, plus documentation updates. For a PM this is a maintainer-discipline signal — the project is actively hardening type safety and regression safety rather than accumulating features. That supports a "low-risk dependency, safe to standardize on" call across multiple Laravel services.
• Dependency standardization. If several product teams each wire up charts differently, mandating one wrapper reduces duplicated JS glue and inconsistent theming. This package is a plausible standard, with the caveat that it only covers ApexCharts.
• Non-decisions it does not inform. It says nothing about data warehouse strategy, event instrumentation, or metric definitions. Do not let "we adopted a chart package" be read as progress on analytics capability.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Laravel/PHP and views are Blade (or Livewire/Inertia with server-provided options); the team is comfortable in PHP and does not want a separate JS SPA just to render charts.
• The need is presentational: dashboards, KPI tiles, trend lines, distribution and comparison charts over data you already know how to query.
• You want ApexCharts specifically — attractive defaults, good interactivity, decent mobile behavior, no React/Vue dependency required.
• You value a small, boring dependency over a large framework; you accept that the wrapper's job is to produce config arrays, and any advanced customization means dropping into raw ApexCharts options.
• Maintenance signals matter to your review process: this release shows CI-enforced static analysis at PHPStan level 8 plus Rector, which is a strong hygiene indicator for a package of this size.

Look elsewhere when:

• You need charts outside Laravel/PHP (Node, Python, Go services) or a shared front-end component library used by multiple apps — you want a JS-first charting library or design-system component, not a PHP wrapper.
• You need true analytics/BI capability: ad-hoc exploration, saved dashboards per user, scheduled delivery, exports, embedded analytics for customers. That is Metabase / Superset / Looker / Power BI territory, and bolting it onto a rendering wrapper will not end well.
• You need heavy client-side interactivity or large datasets: cross-filtering, drill-down, live streaming, or tens of thousands of points. You will want direct ApexCharts control (or a WebGL-based library) rather than server-rendered configs.
• Server-side or scheduled image rendering (PDF reports, emails with chart images) is a requirement — ApexCharts renders in the browser; you would need a headless-browser or image-service pipeline regardless of this package.
• Accessibility or strict design-system compliance is a hard constraint. Chart accessibility is largely on you and upstream ApexCharts; expect manual work.
• You need guaranteed long-term vendor support — this is a community package. Have a contingency: because it emits plain ApexCharts options, the exit cost is low (swap the wrapper for direct JS or another wrapper), which materially softens this risk.

Upgrade note for planning: v10.1.0 is a minor release with no breaking changes — the changes are internal tooling, CI, and docs. No user-facing code changes are expected, so it can ride along with routine dependency updates. There is a minor housekeeping item in the release (a fix to stop the release tooling from forcing the version), which is packaging metadata rather than runtime behavior; verify the installed version reports 10.1.0 after upgrading. The meaningful planning input is the trajectory: the maintainers are progressively tightening static analysis, which may surface type strictness in future majors. Budget a small amount of engineering time for a major-version bump if you customize chart option arrays heavily.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship dashboards and reporting visuals in our Laravel applications using a small, actively maintained open-source package rather than building charting from scratch or buying a BI platform. It is a presentation-layer tool — it draws charts from data we already know how to query — so it accelerates delivery of in-product reporting without committing us to an analytics platform we do not yet need. Cost is effectively zero in licensing, and the exit cost is low because the package produces standard ApexCharts configuration; if we ever outgrow it, we swap the wrapper, not the charts. The latest release contains no new customer-facing features and no breaking changes; it is maintenance hardening (automated refactoring plus static analysis now enforced at a strict level in CI), which is exactly the signal we want when standardizing on a dependency.

For engineering: This is a thin, Blade-friendly wrapper around ApexCharts that turns PHP arrays into chart options — no JS build step required, no framework coupling beyond Laravel. v10.1.0 is a hygiene release: Rector integrated for automated refactoring, PHPStan added to CI and ratcheted from level 1 through level 8, documentation updated, and a fix so the release automation stops forcing the version. No API changes, so the upgrade is a routine composer update — just confirm the resolved version. Adopt it where PHP already owns the data; do not adopt it as an abstraction over multiple charting libraries, and do not use it as a substitute for a BI tool. Expect to drop into raw ApexCharts options for anything non-trivial, and note that it gives us nothing for server-side/PDF chart rendering or accessibility compliance — those stay our responsibility.