Getting Started

This package is a Symfony2 bundle, not a Laravel package. The first decision is whether to use it at all in a Laravel codebase. Composer will almost certainly conflict with Laravel’s modern Symfony components (symfony/options-resolver, symfony/dependency-injection, etc.), and the last release was in 2017. Treat it as a reference implementation, not a direct dependency.

Start by inspecting the package source in an isolated directory:

git clone https://github.com/fados-produccions/ChartjsBundle /tmp/chartjs-bundle

Look first at:

Chart/ — the chart model/builder classes. These are the only parts worth porting.
Resources/config/services.yml — shows how the bundle wires its services.
Twig/ — the Twig extension that renders charts. You will replace this with Blade.
DependencyInjection/ — Symfony-specific configuration; ignore for Laravel.

The first practical use case is a dashboard line chart. Do not try to install the bundle into Laravel. Instead, copy the framework-agnostic chart-building logic into app/Support/Chartjs/ or reimplement a small builder inspired by it. Then render the chart with Chart.js directly from Blade or a Blade component.

Minimal Laravel flow:

Build a chart config array in a controller or dedicated class.
Pass it to a Blade view.
Render a <canvas> and initialize Chart.js with @json($config).

// app/Http/Controllers/DashboardController.php
public function index()
{
    $chart = [
        'type' => 'line',
        'data' => [
            'labels' => ['Jan', 'Feb', 'Mar'],
            'datasets' => [[
                'label' => 'Revenue',
                'data' => [120, 190, 300],
            ]],
        ],
        'options' => [
            'responsive' => true,
        ],
    ];

    return view('dashboard', compact('chart'));
}

{{-- resources/views/dashboard.blade.php --}}
<canvas id="revenue-chart"></canvas>

@push('scripts')
<script src="https://cdn.jsdelivr.net/npm/[email protected]"></script>
<script>
    new Chart(document.getElementById('revenue-chart'), @json($chart));
</script>
@endpush

Implementation Patterns

1. Cannibalize the chart builder, not the bundle

The bundle’s core value is probably its Chart class and option merging. Port those classes into Laravel and replace Symfony’s OptionsResolver with Laravel’s Arr::get / data_get / array_replace_recursive. Keep the public API similar so examples from the bundle still make sense:

namespace App\Support\Chartjs;

class Chart
{
    protected string $type = 'line';
    protected array $data = [];
    protected array $options = [];

    public static function make(string $type): self
    {
        return (new self())->type($type);
    }

    public function type(string $type): self
    {
        $this->type = $type;
        return $this;
    }

    public function data(array $data): self
    {
        $this->data = $data;
        return $this;
    }

    public function options(array $options): self
    {
        $this->options = array_replace_recursive($this->options, $options);
        return $this;
    }

    public function toArray(): array
    {
        return [
            'type' => $this->type,
            'data' => $this->data,
            'options' => $this->options,
        ];
    }
}

2. Use a Blade component for rendering

Replace the bundle’s Twig extension with a reusable Blade component. This is the Laravel-native equivalent and keeps chart initialization out of controllers.

{{-- resources/views/components/chart.blade.php --}}
@props(['id', 'config', 'height' => '320px'])

<div style="height: {{ $height }}">
    <canvas id="{{ $id }}"></canvas>
</div>

@push('scripts')
<script>
    new Chart(document.getElementById(@json($id)), @json($config));
</script>
@endpush

Usage:

<x-chart id="revenue-chart" :config="$chart" />

3. Keep chart configuration in dedicated classes

For day-to-day work, avoid building large chart arrays inline in controllers. Create a small chart class per report:

namespace App\Charts;

use App\Support\Chartjs\Chart;

class RevenueChart
{
    public function build(): array
    {
        return Chart::make('line')
            ->data([
                'labels' => ['Jan', 'Feb', 'Mar'],
                'datasets' => [[
                    'label' => 'Revenue',
                    'data' => [120, 190, 300],
                ]],
            ])
            ->options([
                'responsive' => true,
                'legend' => ['display' => false],
            ])
            ->toArray();
    }
}

This mirrors how the Symfony bundle separates chart construction from rendering and makes charts testable.

4. Add an AJAX/API pattern for dynamic charts

The bundle is server-rendered. In Laravel you will often want charts refreshed via JSON. Return the chart config from a controller and update the chart in JavaScript:

Route::get('/api/charts/revenue', fn () => response()->json(
    (new \App\Charts\RevenueChart())->build()
));

fetch('/api/charts/revenue')
    .then(r => r.json())
    .then(config => {
        const chart = Chart.getChart('revenue-chart');
        chart.data = config.data;
        chart.options = config.options;
        chart.update();
    });

5. If you maintain a legacy Symfony2 app

Use the bundle as intended there: register it in AppKernel, configure fados_chartjs, and call its Twig helper. Do not attempt to share that integration with Laravel. Keep the two codebases separate.

Gotchas and Tips

Dependency conflicts are guaranteed. The bundle targets Symfony2 and old PHP versions. Running composer require fados/chartjs-bundle in a modern Laravel app will likely fail or force unacceptable downgrades. Use a separate checkout or copy the source instead.
The bundle is abandoned. Last release was 2017, with 2 stars and 0 dependents. It does not support Chart.js v3/v4 option schemas, PHP 8, or modern Symfony. Do not put it in a production composer.json.
Twig is not Blade. The bundle’s rendering layer depends on Twig. You must rewrite the rendering as a Blade component or directive. Porting only the PHP chart builder is usually enough.
Symfony service container assumptions. The bundle registers services and compiler passes. Laravel’s container will not resolve those automatically. If you copy classes, bind them manually in a service provider or instantiate them directly.
Chart.js version mismatch. The bundle almost certainly targets Chart.js 1.x or 2.x. If you copy examples, pin [email protected]. If you upgrade to Chart.js 4, rewrite options such as scales.yAxes to scales.y and remove legacy defaults.
JSON encoding in Blade. Use @json($config) rather than {{ json_encode($config) }} to avoid HTML escaping issues inside <script>. If you build JSON manually, use JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP | JSON_HEX_QUOT.
Canvas sizing. Chart.js responsive charts need a container with a defined height. Without it, charts may render at zero height or grow indefinitely.
Debug the config, not the bundle. Before rendering, dd($chart->toArray()) or log the array. Most chart failures are malformed configs, not rendering bugs.
Extension point to preserve. If you port the bundle, keep its Chart class API (make, data, options, toArray) so existing Symfony examples and mental models transfer. Add Laravel-specific features—Blade component, API responses, Livewire events—on top rather than modifying the core builder.
Better alternatives. For new Laravel work, use Chart.js directly via npm/Vite, or a maintained Laravel chart package. The bundle’s only real value here is as a small reference for structuring chart configs.

Chartjs Bundle Laravel Package