Adminlte Laravel Laravel Package

Product Decisions This Supports

• Licensing/compliance sign-off on a shipped product. The prior dependency chain (apexcharts@^6.8) pulled a library that moved off MIT at 5.2.0, with terms that can require a commercial licence when the app is distributed to third parties. For any customer-facing or resold product, that was an unresolved legal exposure sitting in composer.json. v1.7.0 makes the charting stack MIT-only (Chart.js 4). This is a decision-enabler, not a nice-to-have: it unblocks shipping to enterprise procurement and app-store/marketplace review.
• Build vs buy for admin/back-office UI. Adopting this package instead of hand-rolling a Blade admin shell buys: a themed component library, demo dashboards, and now a charting preset that handles Chart.defaults theming from CSS variables, re-theming on light/dark/auto toggle and text-direction change, and resize handling inside tabs, modals and collapsed cards. That last cluster is recurring, low-value engineering work that teams chronically underbudget — it is a legitimate reason to buy rather than build.
• Roadmap item: schedule a migration, don't let it ride. This is a breaking release disguised by a minor version bump. Published views, the published resources/js/adminlte.js stub, and any in-house ApexCharts chart code all keep pointing at a library that is no longer installed. The failure mode is silent — charts render as empty boxes — so it needs an explicit ticket with a checklist, a QA pass over every dashboard, and a grep for ApexCharts in resources/views/vendor/ and resources/js/. Do not let it land as an unrelated dependency bump in someone's sprint.
• Feature scoping: chart export/zoom is now a build item. The ApexCharts toolbar (zoom, SVG/PNG download) is gone with no Chart.js equivalent shipped. If "download this chart" is on the roadmap or in a sales conversation, it is now custom work on top of Chart.js. Reconcile that against the current backlog before committing to it.
• Use-case fit: internal admin panels, back-office CRUD, SaaS operator tooling, agency client portals, MVPs where the dashboard is a supporting surface rather than the product. Less applicable where the chart is the product.

When to Consider This Package

Adopt when:

• You are on Laravel with server-rendered Blade views (Livewire is fine) and need a credible admin shell in days, not months.
• You have a distributed, resold, or customer-facing product and need a dependency tree you can defend in a security/legal review — the MIT-only charting stack is now a genuine differentiator against the previous release.
• You want dark mode, RTL and responsive chart behaviour handled by the package rather than by your team. The window.AdminLteCharts API (create, sparkline, color, alpha, palette, refresh, init) and Chart::config() give hand-written charts the same treatment without forking the preset.
• You are comfortable with the AdminLTE/Bootstrap visual language, or can accept it as the internal-tool baseline.
• The chart needs are conventional: area, line, bar, pie, donut, radar, polarArea, scatter, bubble, sparkline.

Look elsewhere when:

• Your frontend is Inertia/React/Vue with a real component library — you would be paying for Blade components you won't use.
• You need advanced charting: annotations, zoom/pan, image export, financial or high-density time series, or chart-level accessibility. Chart.js covers the common cases; it does not cover those.
• You have strict WCAG obligations. AdminLTE's accessibility posture is weak and this release does not change that; you will be retrofitting.
• The migration cost is unaffordable right now — if you are mid-release with heavily customised published views and in-house ApexCharts code, defer to a dedicated window rather than absorbing it opportunistically. Staying on v1.6.2 means staying on the licensing exposure, so treat deferral as a dated risk acceptance, not a decision to skip.
• You have no charts at all. The headline change is charting; if your admin surface is forms and tables, the upgrade buys you little beyond the bug fixes.

How to Pitch It (Stakeholders)

To executives: This release removes a commercial software licence exposure from our admin dashboard. A charting library we ship to customers changed its terms and could have required us to buy licences once our app is used by third parties. The new version replaces it with an MIT-licensed equivalent at no cost and no loss of the charts we actually use. The trade-off is a bounded engineering task — roughly a day of migration plus a QA pass over each dashboard — and one capability, chart image/zoom export, that we would now have to build ourselves if we want it. Recommend approving the migration as a scheduled item this cycle.

To engineering: Version 1.7.0 swaps ApexCharts for Chart.js 4 and it is a breaking change despite the minor version. composer update alone will not fix published files. The upgrade path is: run the documented adminlte:install --only=assets, uninstall apexcharts, add chart.js@^4.5, re-publish views (preserving local edits), delete the dead ApexCharts block from resources/js/adminlte.js, and remove the apexcharts entry from config/adminlte.php. The chartjs plugin self-registers, so no config edit is required to get charts working. Port any in-house ApexCharts code to AdminLteCharts.create(el, config) to inherit theming and dark-mode handling; the component's props are unchanged, and common options (colors, labels, xaxis.categories, chart.stacked, legend, stroke, axis min/max) are translated automatically — anything else is silently dropped, so audit custom options rather than assuming parity. Two genuine bug fixes land with it: type/height are no longer lost when options contains a chart key, and pie/donut charts now respect categories instead of labelling slices series-1, series-2. The <canvas> id is now the id prop and works with Chart.getChart(id).