Axis Laravel Package

Product Decisions This Supports

• Build vs. buy on charting plumbing. The recurring question for any Laravel product team is whether charting is differentiated. It almost never is. Axis removes the JS wiring tax (roughly 1–3 dev-days per charting surface plus ongoing maintenance) and lets a PHP team ship charts in under an hour. That is a "buy" decision on undifferentiated work, and it is defensible to stakeholders precisely because the alternative cost is measurable.
• Roadmap sequencing for reporting and dashboards. If reporting, admin dashboards, or "insights" surfaces are on the roadmap, Axis changes the estimate from "needs frontend capacity" to "a backend dev can do it." That can pull reporting features forward a sprint or two, or free frontend capacity for genuinely customer-facing work. It is a leverage decision on when you can ship, not just how cheaply.
• Scope decisions inside a feature. Because the fluent API covers a subset of each library's surface, the build/skip line is visible early: standard bars, lines, pies, and series are cheap; bespoke annotations, custom tooltips, and scripted interactions require the raw-config escape hatch and cost more. That gives you a real triage instrument during refinement rather than discovering complexity mid-sprint.
• Feature-tiering and licensing. Defaulting to Chart.js (MIT) keeps charting cost-free at any tier. Highcharts carries commercial licensing obligations that Axis does not alter — so "which library" is a pricing/packaging decision as much as a technical one. Treat Highcharts as an opt-in per surface requiring explicit approval.
• Live-updating dashboard bets. Livewire-readiness (including the #[Axis] attribute that preserves chart instances across re-renders) is the reason to choose this over a generic wrapper. If the product direction is filterable, live dashboards — date ranges, tenant switches, real-time ops views — this is the capability that would otherwise be hand-rolled badly in JS.
• Where to place charting in the risk portfolio. 27 stars, zero dependents, single maintainer, pre-1.0 with breaking changes in minor versions. That is fine for internal/admin surfaces and contained MVP reporting. It is not fine for revenue-critical customer surfaces without a written fork/vendor plan. This is a portfolio-allocation call, not a code call.
• What stays on your roadmap regardless. Accessibility, data-table fallbacks, PNG/PDF/CSV export, dark-mode fidelity, and design-system conformance are not solved by adoption. Budget them explicitly at the point you commit to a customer-facing chart, not later.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Laravel with server-rendered Blade and/or Livewire, and the team is PHP-centric with limited or contended frontend capacity.
• There is no existing, sanctioned design-system chart component. If one exists, Axis creates a second divergent charting path and the trade turns negative.
• The initial surfaces are internal (admin, ops, back-office) or a contained MVP reporting feature — not revenue-critical customer-facing analytics on day one.
• The planned charts are predominantly standard types (bar, line, area, pie, doughnut) that the fluent API covers, with escape-hatch usage expected to stay under roughly a quarter of charts.
• Chart.js is acceptable as the default. Anything requiring Highcharts should be a separate, explicitly approved decision.
• Someone can own the dependency: pin the version, watch releases, and validate rendering on each Livewire/Laravel major.

Look elsewhere — or strip to raw config — when:

• The frontend is Inertia/React/Vue, or the product is SPA-centric. The value proposition is PHP-side authoring; a JS-native team gains nothing and loses flexibility.
• The charts are the product (embedded analytics, customer-facing BI, publication-quality visuals). Requirements for accessibility, export, annotations, custom interactions, and design-system fidelity will exceed the abstraction quickly, and you will pay an indirection tax to write JS config inside PHP strings.
• Your organization requires a vendor, SLA, security-response process, or CVE handling. There is none here, and no user base to lean on for answers.
• You cannot accept a pre-1.0 dependency with breaking changes in minor versions and a single maintainer on a surface you cannot afford to have break.
• A chart is expected to be driven by user or tenant input through Script::from(). That is an injection surface with no built-in guardrail.
• Server-side image rendering is required and your deployment cannot absorb a Node/Chromium runtime in the container.

How to Pitch It (Stakeholders)

To executives: Charting is plumbing, not product. Today every chart costs us one to three developer-days of JavaScript wiring plus permanent maintenance. Axis lets our PHP developers build charts directly, in the language our team is strongest in, cutting that to hours. It is MIT-licensed, works out of the box with Chart.js at no cost, and supports the current Laravel and Livewire versions. The trade is explicit: it is a young, single-maintainer package with a small user base, so we are proposing a gated pilot on internal dashboards — one sprint, written go/no-go criteria — before it touches anything a customer pays for. If the pilot fails or the package stalls, we exit cheaply because we will have wrapped it behind a single internal interface and pinned the version. We are not buying a platform; we are buying back developer-days with a capped downside.

To engineering: This is a translation layer, not a renderer. It turns a fluent PHP builder into native config for Chart.js, ApexCharts, or Highcharts and emits it through a Blade render — no new runtime, no build step, no proprietary engine. The genuinely valuable piece is Livewire instance preservation across re-renders, which is exactly the thing teams hand-roll badly. Two escape hatches bound the risk: raw native config arrays and Script::from() for scripted properties. Adoption rules are non-negotiable: pin the exact version (minor releases have shipped breaking changes), pin the paired JS library version and record it, route dependency bumps to a human, and put every chart behind one internal factory so replacement is a one-file job. Hard rule: never interpolate untrusted or tenant-supplied data into Script::from(). Prove it on one internal dashboard with three chart types, exercise the escape hatch once to learn what raw-config mode costs, then gate the decision on escape-hatch usage rate, defects attributable to the package, and measured time saved. The dependency is small and readable — treat the source as the spec, and keep a documented fork-or-strip plan on file before this reaches a customer surface.