C3Charts Bundle Laravel Package

Getting Started

First, the reality check: this is a Symfony bundle, not a Laravel package. It has no service provider, no Blade directives, and no config/c3charts.php to publish. Its only release is from 2018-11-20, it has 4 stars and 0 dependents, and the underlying C3.js library is itself in maintenance mode. For a Laravel developer, "getting started" is really a decision point:

1. If you have a Symfony app in the same shop — composer require muspelheim/c3charts-bundle, register it in config/bundles.php (or AppKernel on older Symfony), and start with the bundle's Twig extension to render a chart from a controller.
2. If you are purely Laravel — do not install it and expect it to work. Instead, read the source as a reference implementation for building C3.js option arrays in PHP, and port the small amount of chart-building logic into a plain service class you register in a Laravel service provider.

Where to look first:

• The bundle's src/ directory: chart-building classes (the PHP that assembles C3's data, axis, bindto, tooltip config) and the Twig extension that exposes the render function.
• The bundle's Resources/views (or equivalent) for the template that outputs the <div id="..."> and the c3.generate({...}) call.
• Its composer.json — check the Symfony version constraints before assuming it runs on anything modern.

Minimal first use case (Symfony context): load d3 and c3 (CDN or asset pipeline), render the bundle's chart tag into a container <div>, and pass a simple ['data' => ['columns' => [['data1', 30, 200, 100]]]]-shaped array. The bundle's value is converting PHP arrays into the exact JSON C3 expects plus the init script.

Minimal first use case (Laravel context): skip the bundle entirely. Add c3 + d3 via npm/Vite, then produce the options array server-side in a small ChartFactory class and hand it to a Blade component that calls c3.generate(). You keep 90% of the bundle's benefit with none of the framework mismatch.

Implementation Patterns

Controller-builds-chart pattern (the bundle's intended shape). Construct a chart object in the controller, set series/axes/type, pass it to the view, and let the Twig extension emit the markup + JS. Mirror this in Laravel with a dedicated class rather than fattening controllers:

// app/Support/Charts/ChartConfig.php (ported idea)
final class ChartConfig
{
    public static function line(array $series): array
    {
        return [
            'bindto' => '#revenue-chart',
            'data' => ['columns' => $series, 'type' => 'line'],
            'axis' => ['y' => ['label' => 'Revenue']],
        ];
    }
}

Blade component wrapper. Wrap the output so your views stay clean and the C3 dependency is isolated:

{{-- resources/views/components/c3-chart.blade.php --}}
<div id="{{ $id }}" wire:ignore></div>
@push('scripts')
<script>
  document.addEventListener('DOMContentLoaded', () => {
    c3.generate({!! Illuminate\Support\Js::from($config) !!});
  });
</script>
@endpush

Livewire / Inertia integration. Charts are client-side; if data changes reactively, keep the config in a public property and re-run c3.generate() (or chart.load()) in a $watch/updated hook. The bundle has nothing to offer here — this is where a port beats the package.

API-driven series. The strongest day-to-day pattern is: JSON endpoint (Route::get('/api/charts/revenue')) returns series arrays; the Blade shell is static; the JS fetches and renders. This avoids re-rendering server templates and sidesteps the fact that the bundle's server-side rendering is static snapshot only.

Multi-chart dashboards. Give each chart a unique bindto id; the bundle historically assumes a single chart per render call, so a dashboard is just N component inclusions. In Laravel this maps cleanly onto a <x-c3-chart> component in a loop.

Gotchas and Tips

• It is not a Laravel package. No auto-discovery, no ServiceProvider, no facades. composer require will install Symfony bundles and Twig as transitive deps, bloating a Laravel app. Treat it as a reference implementation, not a dependency.
• Twig dependency is the dealbreaker. The rendering lives in a Twig extension. Pulling Twig into Laravel to render charts is a heavy, confusing trade for a template function you can reimplement in a Blade component in ~20 lines.
• 2018-era PHP code. Expect PHP 7.x syntax and Symfony 3/4 constraints. On PHP 8.1+ you may hit deprecations or fatal errors from type mismatches. Check composer.json require before anything else.
• C3.js itself is in maintenance mode (D3 v5-era). New projects should prefer Chart.js, ECharts, or ApexCharts. Adopting this bundle doubles down on a deprecated chain: abandoned bundle → deprecated C3 → older D3.
• Zero dependents / 4 stars means no community safety net. No security updates, no issue triage, no Stack Overflow answers. Budget for reading the source yourself if anything breaks.
• Load order matters for debugging. Blank chart = usually d3 not loaded before c3, or the bindto selector not present at DOMContentLoaded. Check the console for c3 is not defined and verify the container <div> id matches exactly (including #).
• Escaping. If you copy the bundle's pattern of interpolating config into a <script> tag, ensure it is JSON-encoded safely (Laravel's Js::from() / @json). The 2018 code likely predates strict CSP/escaping habits.
• Extension points (Symfony side): subclass the chart classes or override the bundle's templates to change markup. On the Laravel side, the equivalent extension point is your own ChartFactory — keep it small, typed, and returning pure arrays so it stays testable (assertSame on the options array is a great unit test).
• Migration tip: if you inherit a Symfony app using this bundle, freeze the C3 version, pin the bundle, and isolate all chart rendering behind a single service so you can swap to a JS-first approach later without touching controllers.