Consoletvs Charts Temp Laravel Package

Getting Started

This release (6.5.6) is a community stop-gap published while consoletvs/charts is unavailable — a drop-in continuation of the 6.x line rather than a new API. Treat it as a maintenance fork, not a feature release.

1. Swap the dependency in composer.json. Because the upstream name is offline, you'll usually be pulling this via an explicit VCS/path repository or a renamed package. Confirm the vendor name and that the autoloaded namespace still resolves to ConsoleTVs\Charts\...; if it does, your application code needs no changes at all.
2. Check version parity. 6.5.6 tracks upstream 6.x. If you were on consoletvs/charts: ^6.0, pin this fork to 6.5.* so future upstream-style releases stay compatible, and add a replace entry if another package still requires the original name.
3. Publish config and assets if you haven't already:

   php artisan vendor:publish --provider="ConsoleTVs\Charts\ChartsServiceProvider"
   

   Review config/charts.php before writing any chart code — the CDN vs. local-asset switch and the default library live there.
4. First use case — a dashboard line chart. Build the chart in the controller, return it to the view, and render container + script:

   use ConsoleTVs\Charts\Classes\Chartjs\Chart;
   
   $chart = new Chart;
   $chart->title('Signups');
   $chart->labels(['Jan', 'Feb', 'Mar']);
   $chart->dataset('Signups', 'line', [12, 19, 27]);
   
   return view('dashboard', compact('chart'));
   

   <div class="card-body">
       {!! $chart->container() !!}
   </div>
   
   @push('scripts')
       {!! $chart->script() !!}
   @endpush
   

That five-minute path (controller → container() → script()) covers the majority of day-to-day usage; everything else is dataset and options tuning.

Implementation Patterns

Controller-composes, view-renders. Keep chart construction in a dedicated action or a small ChartBuilder/DashboardMetrics service so the same chart can be reused across a page and a JSON endpoint. Returning ['container' => $chart->container(), 'script' => $chart->script()] from an AJAX/Livewire action is the cleanest way to refresh a chart without a full page reload.

One chart per variable, one script per chart. script() emits an inline <script> bound to that chart's generated ID. Never loop over {!! $chart->script() !!} inside a dataset loop, and don't share a single $chart instance across two containers — clone or rebuild instead.

Stack multiple datasets on one instance rather than creating sibling charts, so tooltips and legends stay coherent:

$chart->dataset('Mobile', 'line', $mobile)->options(['borderColor' => '#0d6efd']);
$chart->dataset('Desktop', 'line', $desktop)->options(['borderColor' => '#6c757d']);

Serve data from an API when the series is large. For 1k+ points, render an empty chart shell and fetch series in JS, or generate the chart in a queued/export context. Inline script() output bloats the HTML payload fast.

Multi-library strategy. If you use more than one backend (Chart.js for dashboards, a different renderer for PDF exports), resolve the class from a config map instead of hard-coding new Chart throughout the app — that keeps the eventual return to upstream a one-line config change.

Blade partials. Wrap container() + script() in a <x-chart :chart="$chart" /> component so @push('scripts') handling, empty-state fallbacks, and responsive wrappers are written once.

Testing. Chart objects expose their datasets; assert on the model/service output rather than HTML. For the rendered view use $response->assertSee($chart->id, false) and assertSee('new Chart', false) — the markup is raw script, so escaping assertions will mislead you.

Gotchas and Tips

• This is a survival fork, not a roadmap. The release note explicitly frames it as "something people can use until consoletvs/charts is back online." Pin an exact version (6.5.6), commit composer.lock, and mirror the package into your own VCS or Satis if uptime matters. Do not build long-term architecture on it without an exit plan.
• Namespace collisions are the #1 upgrade hazard. If anything else in your dependency tree still declares ConsoleTVs\Charts, Composer will either refuse to install or you'll get "cannot redeclare class" at runtime. Resolve with an explicit replace block and verify with composer why consoletvs/charts.
• {!! !!} is mandatory and dangerous. Both container() and script() return HTML with inline JS. Blade's {{ }} will print escaped markup and silently break the chart — a very common first-day bug.
• Script ordering. If you render script() in <head> before the container exists, or before the Chart.js CDN tag, you get a blank canvas and a console error. Keep it in a @push('scripts') stack rendered at the end of <body>, after the library tag.
• Chart.js major-version drift breaks options(). Options arrays are passed through raw, so the object schema is whatever the loaded Chart.js expects. scales: { yAxes: [...] } (v2) versus scales: { y: {...} } (v3+) is the classic failure — the chart renders but axes are ignored with no error. Pin the Chart.js version in config/charts.php and document it.
• Double-render on Livewire/Inertia. A re-render replaces the <canvas> but leaves the old Chart instance registered to a dead DOM node. Either key the component so a fresh ID is generated, or dispose the previous instance from Livewire.hook('message.processed').
• CSP and inline scripts. If you ship a Content-Security-Policy with script-src lacking 'unsafe-inline', script() is blocked silently in production only. Prefer nonce-aware output or move chart init into a compiled JS file fed by a JSON payload.
• Debugging checklist when a chart is blank: (1) is the CDN tag actually in the DOM, (2) does $chart->id appear exactly once, (3) is the script below the container, (4) check the console for Chart is not defined, (5) json_encode the dataset to confirm no INF/NaN values — a single non-numeric point nulls the whole series.
• Extension point. Custom chart classes extend the base Chart and override container()/script() or set $library/$type. That is the supported way to add a renderer or a house style; avoid editing files in vendor/, since a future 6.5.7 will overwrite them.
• Watch the upstream situation (the linked thread) before planning a return migration. If the original returns under a 7.x with a new namespace or a facade-based API, the cheapest migration is the config-map approach above plus a single composer requirement change.