Amcharts Bundle Laravel Package

Getting Started

Read the room first: this is a Symfony2 bundle, not a Laravel package. There is no service provider, no facade, no config publishing. composer require rcousens/amcharts-bundle in a Laravel app will pull in a package that expects Symfony\Bundle\FrameworkBundle and Symfony\Component\DependencyInjection — and the last release was July 2014, so those expectations are for Symfony 2.x-era APIs. You will get a class-not-found error the moment autoloading touches the bundle class.

So treat this as a reference implementation, not a dependency. The realistic first use case:

1. Skim the source, don't install it. The repo is tiny — the value is in the Chart/ChartBuilder-style classes that assemble AmCharts' JSON config object (data provider, category axis, value axis, series/graphs) and emit it to a Twig template. Read those two or three files, understand the shape of the config array, and close the tab.
2. Vendor AmCharts yourself. Add the AmCharts 3.x JS + CSS to public/vendor/amcharts/ (or pull via npm and let Vite copy it). The bundle never handled the JS assets in any meaningful way — that was always your job in the layout.
3. First real use case: a dashboard page with one bar chart fed by an Eloquent aggregate. Build the config array in a controller or a small ChartConfig value object, json_encode it into a data-chart attribute, and bootstrap AmCharts from a single resources/js/charts.js entry that finds those attributes and calls AmCharts.makeChart().

If you genuinely need the Symfony bundle (i.e. you're maintaining a Symfony 2 app, not a Laravel one), register it in AppKernel::registerBundles() and check Resources/config/services.xml for the service IDs — but that is out of scope for a Laravel codebase.

Implementation Patterns

Config-as-array, rendered as JSON. The bundle's whole model is: build a PHP array describing the chart, serialize it, hand it to AmCharts on the client. Reproduce that in Laravel with a small dedicated class rather than scattering arrays through controllers.

// app/Support/Charts/BarChart.php
final class BarChart
{
    public function __construct(
        private array $rows,          // [['label' => 'Jan', 'value' => 42], ...]
        private string $id = 'chart-1',
    ) {}

    public function toArray(): array
    {
        return [
            'type' => 'serial',
            'theme' => 'light',
            'dataProvider' => $this->rows,
            'valueAxes' => [[
                'position' => 'left',
                'title' => 'Orders',
            ]],
            'graphs' => [[
                'balloonText' => '[[category]]: [[value]]',
                'fillAlphas' => 0.8,
                'lineAlpha' => 0.2,
                'type' => 'column',
                'valueField' => 'value',
            ]],
            'categoryField' => 'label',
            'categoryAxis' => ['gridPosition' => 'start'],
        ];
    }
}

Bridge pattern for Blade. Mirror what the bundle did for Twig: pass the encoded config to the view and let a JS module pick it up. Avoid inlining <script> blocks per chart.

<div class="amchart" id="{{ $chart['id'] }}"
     data-config="{{ json_encode($chart['config'], JSON_THROW_ON_ERROR) }}"></div>

// resources/js/charts.js
import * as AmCharts from '/vendor/amcharts/amcharts.js';

document.querySelectorAll('.amchart').forEach(el => {
    AmCharts.makeChart(el.id, JSON.parse(el.dataset.config));
});

Reusable chart types. The bundle's value was a handful of pre-wired chart flavours (pie, serial, xy). Recreate them as a small factory — Chart::pie($rows), Chart::serial($rows, $graphType) — so your controllers never name AmCharts keys directly. This keeps the AmCharts 3 → 4 migration surface confined to one directory.

Data shaping belongs server-side. AmCharts 3 expects a flat array of objects with consistent keys. Do the aggregation in SQL (selectRaw('DATE(created_at) as label, COUNT(*) as value')), not in the view, and cast numerics so AmCharts doesn't render string values as gaps.

Integration tip — API + AJAX for large datasets. For anything over a few thousand points, don't embed the JSON in HTML. Emit only a config with dataLoader: { url: route('charts.data', $chart) } and return the array from a JSON controller. This matches AmCharts' own documented pattern and keeps your Blade payloads small.

Gotchas and Tips

• Symfony 2 is the dealbreaker. The bundle's service definitions and getContainerExtension() plumbing assume Symfony DI. There is no Laravel bridge and there never will be for a 2014 package. Do not add this to composer.json "just in case."
• AmCharts 3, not 4/5. The API in this bundle is AmCharts.makeChart() with graphs/valueAxes. AmCharts 4+ renamed everything (am4core, Series, create()). If you copy the config arrays verbatim into a modern AmCharts build, nothing renders — you'll get silent empty canvases because unknown keys are ignored.
• Licensing is your problem, not the bundle's. AmCharts 3 JS is free for commercial use provided you keep the small "amCharts" branding link. The MIT license here covers the PHP bundle, not the JS library. Don't strip the credit unless you've bought a license.
• JSON encoding of decimals. PHP will encode 42.0 as 42 and float-precision surprises can surface in tooltips. Cast with (float) and consider JSON_PRESERVE_ZERO_FRACTION if the tooltip formatting depends on it.
• Empty datasets render an empty grid, not an error. AmCharts 3 is silent when dataProvider is []. Add a guard in Blade to show an "no data yet" partial — this is the single most common dashboard bug report.
• id collisions. AmCharts.makeChart(id, ...) binds to a DOM id. Two charts with the same generated id (easy with a Blade @foreach) produce one chart and one blank box. Generate ids from a stable key, not $loop->index alone.
• Extension points, if you must stay on Symfony. The bundle exposes its chart classes as services and allows overriding templates via Resources/views. Anything you'd "extend" in Laravel is really: your own ChartConfig class — keep it final-ish and covered by one unit test that asserts the encoded JSON matches a fixture. That test is what makes the eventual AmCharts version bump survivable.
• Debugging: AmCharts 3 logs nothing useful by default. Set AmCharts.charts in the console after page load — if the chart object isn't there, the failure is in your JSON parse or the makeChart id lookup, not in the chart options.
• Don't hunt for documentation on the repo. Three stars, no releases since 2014, zero dependents: there are no tutorials, no issue answers, and no forks worth reading. Go straight to the AmCharts 3 reference for config keys; the bundle is only a thin array-builder over that same spec.