Lavacharts Laravel Package

Product Decisions This Supports

• Build vs. buy for reporting UI. Lavacharts lets you ship charts without building a rendering layer: you describe a chart in PHP, it emits the Google Charts JS. That converts a "do we staff a front-end charting workstream?" decision into a small dependency decision — valuable when charting is supporting infrastructure, not the product. The 3.1.14 Composer 2 fix removes an install-time blocker that previously made even a trial adoption a chore on modern Composer.
• Scope of an internal analytics/admin surface. Good fit for decisions like "v1 of the customer dashboard shows 4 chart types (line, bar, pie, geo)." The wrapper covers the common Google Charts catalogue, so scope can be set by product need rather than by what the front end can build in time.
• Sequencing on the roadmap. If reporting is a later milestone, adopting a thin wrapper now defers the real investment (a charting design system, a metrics layer, a BI tool) until you know which charts users actually open. Treat it as a spike-enabler, not a platform commitment.
• Time-to-value for prototypes and demos. For sales demos, internal tools, and MVP dashboards, this is a days-not-weeks decision. That matters when the alternative is blocking a launch on front-end capacity — and 3.1.14 means we can validate the spike on a current Composer 2 toolchain without patching vendor code first.
• Buy-vs-adopt against heavier alternatives. It's a cheap way to test demand for analytics before committing to Metabase/Superset-style BI, or to Chart.js/ApexCharts plus a JS build step.
• Concrete use cases: admin KPI dashboards, back-office operational reports, geo breakdowns, internal anomaly/trend views, prototype data explorers. Poor fit for anything customer-facing that needs a bespoke visual language.

When to Consider This Package

Consider it when:

• The application is an internal or low-exposure surface — admin panels, back-office tooling, prototypes — where a Google-styled chart is acceptable.
• You are on, or pinned to, a legacy PHP/Laravel stack (PHP 5.4–7.x, Laravel ≤6/7). This is where the package's actual compatibility lives.
• You are on Composer 2. The 3.1.14 patch (2024-era, fixing the RenderableTrait blocker, issue #322) specifically unblocks Composer 2 installs, so a modern-composer shop can now evaluate it without forking. Confirm in a spike that this is the only install blocker on your matrix.
• You need a specific Google Charts capability that is expensive elsewhere — Geo charts, gauges, trendlines, annotations, combo charts — and you want it in an afternoon.
• You want charts described server-side in PHP so the team owning the data also owns the visualization, with no JS build pipeline.
• You accept rendering from Google's CDN at runtime (client must reach the internet; Google sees the request).

Look elsewhere when:

• New projects on PHP 8.1+/Laravel 9+. 3.1.14 is a narrow install/compatibility patch, not a framework-support release — it does not claim PHP 8.x or modern Laravel support. Verify against your actual matrix before it reaches a sprint; budget for a fork if it fails.
• Any sustained maintenance or security commitment is required. One patch after a dormancy back to 2020-11-23 is a sign of life, not a support contract — there is still no patch SLA and no visible maintainer bench. If your org requires a supported dependency for anything touching production data, this still fails that gate.
• License clarity is mandatory. Metadata still reports NOASSERTION rather than a detected license. Historically MIT, but a PM should get legal sign-off rather than assume — this is a 30-minute check that can invalidate the whole plan.
• Data residency, GDPR, or offline/air-gapped requirements apply. Google Charts loads from Google's servers. For regulated, EU-resident, or on-prem customers, this is disqualifying — use a self-hosted renderer (Chart.js, ApexCharts, ECharts).
• You need server-side image export (PDF reports, emailed charts, exports) or headless rendering. Google Charts' JS-first model fights this; plan a separate path.
• The charts are a customer-facing product surface. You'll want design control, theming, and accessibility ownership that a thin wrapper doesn't give you.
• The "0 dependents" signal concerns you. Whether it's a metadata artifact or real, it argues for treating adoption as a fork-and-own decision, not a vote of confidence.

How to Pitch It (Stakeholders)

To executives: Lavacharts is a low-cost, high-speed way to put charts into internal tools. It wraps Google's free charting engine, so there's no license fee and no front-end build effort — a reporting dashboard that would otherwise take a month of engineering can land in days. A recent patch (3.1.14) fixed the Composer 2 installation blocker, so we can now trial it on our standard toolchain without vendor hacking. The trade-off is unchanged: it's a tactical accelerator, not a strategic platform — it went roughly four years without a release, its license needs a quick legal confirmation, and it renders by pulling scripts from Google's CDN, which rules it out for regulated or customer-facing surfaces. My recommendation is to use it for internal dashboards and prototypes where it buys real schedule, and to keep an explicit exit path — the chart definitions are simple enough to port to a maintained library if reporting becomes a product priority.

To engineering: It's a thin PHP wrapper over the Google Charts JS API — you define chart config in PHP, it emits the JS. That means no new build tooling and no JS ownership for the data team. 3.1.14 only addresses the RenderableTrait Composer 2 blocker (#322); treat it as an install fix, not evidence that PHP 8 / current Laravel is supported — validate that in a one-day spike before committing. The other costs are a runtime dependency on Google's CDN, a client-side rendering model (so no clean server-side/PDF export), and a thin maintenance record — assume we may fork and pin it. If we go ahead, isolate chart definitions behind one service so swapping renderers later is a contained change.