Getting Started

Install it like any Filament plugin dependency, then register the widgets you actually want on a panel:

composer require laraveldaily/filawidgets

// app/Providers/Filament/AdminPanelProvider.php
public function panel(Panel $panel): Panel
{
    return $panel
        ->default()
        ->id('admin')
        ->path('admin')
        ->widgets([
            // Confirm exact class names from the package README / src/
            \LaravelDaily\FilaWidgets\Widgets\SomeStatsWidget::class,
        ]);
}

Where to look first, in order:

The README's widget list — this is the entire product surface. Everything else is Filament knowledge you already have.
vendor/laraveldaily/filawidgets/src/ — these are small classes extending StatsOverviewWidget, ChartWidget, or TableWidget. Read one end-to-end; you'll understand the whole package in ten minutes.
composer.json of the package — check the filament/filament constraint (^3.0 vs ^4.0). This is the single biggest compatibility risk.
config/filawidgets.php if it exists — publish with php artisan vendor:publish --provider="LaravelDaily\FilaWidgets\FilaWidgetsServiceProvider" and check the tags it exposes.

First use case: drop one stats widget onto a non-critical dashboard page and confirm the full pipeline works — composer autoload → panel registration → render → data query. Don't start by customizing three widgets at once; you want to isolate whether a failure is registration, Filament version, or your query.

A framing note before you invest: 48 stars means this is a widget collection / starter kit, not a framework. Treat it as a curated set of reference implementations you can extend or copy into app/Filament/Widgets, not as a dependency your product's dashboard architecture rests on.

Implementation Patterns

Extend vs. copy. Two valid workflows, pick deliberately:

Extend (class RevenueChart extends \LaravelDaily\FilaWidgets\Widgets\...) when you're only changing getData(), labels, or colors. You inherit upstream fixes but are coupled to their class names and protected properties.
Copy into app/Filament/Widgets/ when you're changing layout, adding filters, or doing anything non-trivial. Widgets are ~50-line classes; the copy is cheap and you stop caring whether the package is maintained.

A reasonable default: extend for the first week to evaluate, copy once you've touched a widget more than twice.

Override the data method, not the view. The shipped widgets follow standard Filament contracts, so customization stays boring:

// Stats
protected function getStats(): array
{
    return [
        Stat::make('Orders today', Order::whereDate('created_at', today())->count())
            ->description('vs yesterday')
            ->descriptionIcon('heroicon-m-arrow-trending-up')
            ->color('success'),
    ];
}

// Chart
protected function getData(): array
{
    return [
        'datasets' => [[
            'label' => 'Revenue',
            'data'  => $this->revenueByDay(),
        ]],
        'labels' => $this->lastSevenDayLabels(),
    ];
}

Keep queries out of the widget. Put aggregates in an action or query class (app/Queries/Dashboard/RevenueByDay.php) and call it from getData(). Widgets are hard to unit test; query classes are trivial to test and reusable across the dashboard and any API/export.

Gate every widget. Filament widgets are not permission-aware by default. If the package ships an "all orders" table widget and you register it, every panel user sees it:

public static function canView(): bool
{
    return auth()->user()->can('viewAny', Order::class);
}

Use canView() (not just visible()) so the widget is excluded from the widget list, not merely hidden client-side.

Layout control. Set these explicitly or the dashboard grid will look arbitrary:

protected static ?int $sort = 3;
protected int|string|array $columnSpan = 'full'; // or 1..12

Multi-panel and tenant scoping. Register widgets per panel rather than globally. For tenant dashboards, resolve tenant inside the query (Filament::getTenant()), not via a global scope alone — it makes the widget's behavior obvious when you revisit it.

Testing. Widgets are Livewire components; smoke-test them cheaply:

Livewire::test(RevenueChart::class)
    ->assertSuccessful()
    ->assertSee('Revenue');

Add one such test per registered widget. It catches the most common real failure: the widget renders on your machine but 500s for a role with different data or a null tenant.

Gotchas and Tips

Filament major version is the whole ballgame. Chart widget APIs and StatsOverviewWidget internals differ between Filament 3 and 4. Confirm the package's constraint matches your app before composer require, and pin it. A widget package built for v3 will install into a v4 app and fail at render time, not at install time.
Double registration. If you use ->discoverWidgets(in: app_path('Filament/Widgets'), for: 'App\\Filament\\Widgets') and list package widgets in ->widgets([]), you're fine — but if you ever point discovery at a broad path, you can register the same widget twice and get duplicated dashboard blocks. Symptom: identical cards stacked. Fix: keep package widgets in the explicit widgets() array only.
Cached components after installing. Filament caches component discovery. New widgets won't appear until you clear it:
```
php artisan filament:clear-cached-components
# or on older versions
php artisan optimize:clear
```
If a widget "doesn't show up," this is the first thing to try — before debugging the class at all.
Every dashboard load runs every widget's queries. Stats and charts are not lazy by default. Four widgets × three aggregates = twelve queries per admin page load. Cache the heavy ones (Cache::remember('dashboard.revenue', 300, ...)) and make sure your date columns are indexed. This is the most common production regression from adding dashboard widgets.
Timezone drift in charts. DB::raw('DATE(created_at)') groups by the database session timezone; now() uses config('app.timezone'). If those differ, your "today" bucket is silently wrong near midnight. Either store UTC and convert at the edge, or group explicitly in app timezone.
Unbounded table widgets. A TableWidget without a default sort and sensible pagination will happily try to render large result sets. Always set ->defaultSort('created_at', 'desc') and keep pagination on.
Publishing tags are guesswork — list them first. Don't assume --tag=views exists. Run php artisan vendor:publish interactively and read the provider list. If there's no config file, there's nothing to publish; don't go looking for one.
Maintenance risk is real but cheap to absorb. With modest adoption, expect slow fixes for new Filament releases. Mitigation is trivial because the widgets are small: copy the classes into app/Filament/Widgets, drop the dependency, and you've eliminated the risk in an afternoon. Budget for that rather than being surprised by it.
Don't build a product architecture on it. Use it to get a dashboard up fast and to learn idiomatic Filament widget structure. Your own widgets in app/Filament/Widgets should be the long-term home for anything business-critical.

Filawidgets Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips