Ux Echarts Laravel Package

Product Decisions This Supports

• Build vs. buy for data visualization: hecht-a/ux-echarts is a thin PHP/Twig bridge over Apache ECharts (MIT, JS-side). It answers the "do we hand-roll a charting layer?" question cheaply on the server-rendering side, while leaving the actual rendering engine to a mature, widely adopted open-source library. The decision it supports is "compose, don't build."
• Dashboard and reporting roadmap: if any roadmap item involves admin analytics, KPI tiles, time-series reporting, or embeddable charts in a Twig-rendered app, this package is a plausible delivery vehicle — configuration lives in PHP, so chart definitions can be generated from the same domain services that produce the data.
• Framework upgrade sequencing: v2.2.0 adds Symfony 8 support. That is an enabler, not a feature — it means the chart layer does not become the blocker on a Symfony 8 upgrade program. Treat it as an input to upgrade planning and dependency-freeze decisions rather than a reason to adopt.
• Front-end vs. back-end ownership: adopting it signals that chart configuration is owned by backend/Twig developers rather than requiring a dedicated SPA charting stack. That is an organizational decision as much as a technical one.
• Vendor and maintenance risk posture: the release cadence (a small, targeted compatibility bump) is evidence the package is maintained, but the single-maintainer profile should feed into the dependency-risk register alongside the adoption decision.

When to Consider This Package

Consider it when:

• The application is Symfony-based and renders views through Twig — this package is built for the Symfony UX ecosystem, not Laravel. Laravel teams should treat it as prior art, not a drop-in: the underlying ECharts JS library is framework-agnostic, so a Laravel app would typically consume ECharts directly (or via Inertia/Livewire) rather than through this bundle.
• Charts are declarative and server-configurable — options assembled from PHP arrays/objects, driven by backend data, with modest interactivity (tooltips, legends, series toggles).
• You want to avoid duplicating chart configuration in JavaScript, keeping one source of truth in PHP.
• You are on, or planning, Symfony 6/7 and now 8, and want a supported upgrade path. v2.2.0 makes Symfony 8 a viable target.
• You already use the Symfony UX / Stimulus toolchain and want consistent integration rather than a bespoke bridge.

Look elsewhere when:

• The stack is Laravel or another non-Symfony PHP framework — the Twig/UX coupling makes this a poor fit; budget for a direct JS integration instead.
• You need rich client-side interactivity — drill-downs, live streaming updates, cross-filtering, custom rendering — where a dedicated JS charting layer or a full SPA charting stack is the better owner.
• You need guaranteed commercial support, SLA, or a large maintainer base. This is a small, single-maintainer package; if procurement requires vendor backing, this will not clear the bar.
• You require accessibility-first or export-heavy charting (server-side PDF/PNG rendering, WCAG-audited chart components) out of the box — plan for additional work or a different tool.
• You want zero JavaScript asset management — ECharts still has to be shipped to the browser; this package does not remove that dependency.

How to Pitch It (Stakeholders)

One-liner: a small, free, MIT-licensed Symfony bundle that lets our PHP/Twig code define Apache ECharts charts directly, instead of maintaining a parallel JavaScript charting layer.

For executives: This is a low-cost composition choice, not a platform commitment. We are not buying a charting product; we are adopting a thin, permissively licensed adapter over a well-established open-source visualization library. The v2.2.0 release is a compatibility update — it adds Symfony 8 support — which is the signal that matters: the package will not hold back our framework upgrade. Risk is concentrated in the fact that it is maintained by a single author, so we should treat it as a replaceable component with a clear exit path rather than a foundational dependency.

For engineering: The API surface is small — chart configuration expressed in PHP, rendered through Twig, with ECharts doing the drawing. That keeps chart definitions close to the data services that produce them and removes a class of "the numbers look different in the frontend" bugs. v2.2.0 is additive only: Symfony 8 support, no breaking changes, no deprecations, so it is a safe minor upgrade. Two caveats to plan around: (1) it is Symfony/Twig-coupled, so it is not the right vehicle if the stack or the front end diverges from that; (2) the ECharts JS bundle remains our asset-management responsibility, and ECharts major-version upgrades are ours to track independently of this package's release cycle.

Recommended posture: adopt where the Symfony + Twig fit is genuine and charting needs are declarative; pin the version, keep the chart-configuration layer thin and behind our own abstraction so the bundle is swappable, and re-evaluate if maintenance lapses or a Symfony major bump goes unsupported for more than one cycle.