Filament Daisy Ui Themes Laravel Package

Getting Started

The package is a standard Filament plugin: osamanagi/filament-daisy-ui-themes, namespace Nagi\FilamentDaisyUiThemes, plugin class FilamentDaisyUiThemesPlugin. It targets Filament 4/5 and PHP 8.2+ — there is no Filament 3 path, so check composer show filament/filament before you start.

Minimal sequence:

composer require osamanagi/filament-daisy-ui-themes

# Publish the compiled CSS/JS assets (required — without this you get stock Filament colors)
php artisan vendor:publish --tag="filament-daisy-ui-themes-assets"

# Optional: config + views + translations
php artisan vendor:publish --provider="Nagi\FilamentDaisyUiThemes\FilamentDaisyUiThemesServiceProvider"

Register the plugin on a single panel first — not all of them:

use Nagi\FilamentDaisyUiThemes\FilamentDaisyUiThemesPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(FilamentDaisyUiThemesPlugin::make());
}

If you intend to author or adjust palettes rather than use the shipped ones, you also need the Node side of the package:

npm install
npm run build:themes   # generates the pinned daisyUI theme assets + data
npm run check:themes   # fails if committed output has drifted

Where to look first, in this order:

1. src/FilamentDaisyUiThemesPlugin.php — the actual configuration surface (theme name, dark-mode handling, asset registration). This is the source of truth; the description is marketing copy.
2. The published config/ file — theme selection, default palette, CSS variable overrides.
3. resources/css/ and resources/js/index.js — what actually lands in resources/dist/ and what the published assets contain.
4. Nagi\FilamentDaisyUiThemes facade — the runtime API you would drive a theme switcher from.

First use case: one non-critical panel, one light/dark pair, no custom palettes. Success signal is concrete: inspect the panel root element and confirm data-theme="<your-theme>" is present, and that daisyUI-styled buttons/inputs render. If you see stock Filament blues and greys, registration or asset publishing failed — stop and fix that before going further.

Implementation Patterns

Verify via the DOM, not screenshots. The whole package is one contract: a data-theme attribute on the panel root plus daisyUI CSS variables underneath it. A quick assertion in a Pest/Livewire test (->assertSee('data-theme=', false) on the panel route, or a DOM query in a browser test) catches the "plugin registered but assets missing" failure mode that reviews never catch.

Wrap theme selection behind your own layer. This is the single most valuable pattern with this package, because it is a 5-star, 0-dependent, single-maintainer dependency. Never let FilamentDaisyUiThemesPlugin::make()->theme($tenant->theme) appear in ten panel providers. Instead:

// app/Support/Theming/ThemeResolver.php
final class ThemeResolver
{
    public const FALLBACK = 'corporate';

    public function forPanel(string $panelId): string
    {
        return Tenant::current()?->daisy_theme
            ?? config("theming.panels.{$panelId}", self::FALLBACK);
    }
}

Then the panel provider does exactly one thing with the package. Swapping the package for a hand-written Filament theme later means rewriting one class, not auditing the app.

Per-panel theming. Filament panel providers are per-panel by design, so use that: register the plugin only on panels that need daisyUI (admin, tenant dashboards) and skip it on internal/ops panels. Mixed panels are where CSS conflicts get painful, and opting out is cheaper than debugging.

Per-tenant / white-label branding. The realistic workflow:

1. Store a theme slug per tenant (settings table or a theme column), not raw CSS.
2. Resolve it in the panel provider or a middleware that runs before render.
3. Cache the resolved slug per tenant — it is read on every admin request and should not hit the DB.
4. Ship a fixed, reviewed set of theme slugs. Free-text theme names from a customer-facing form is how you get a panel pointing at a non-existent data-theme and an unstyled admin.

Light/dark as a paired theme, not a boolean. daisyUI models dark mode as another named theme. Treat light/dark as a pair chosen together (corporate ↔ business, light ↔ dark) so Filament's dark-mode toggle doesn't land on an undefined theme. Validate the pair in config, not at render time.

Custom palettes: treat themes as build output. If you need brand colors daisyUI's stock themes don't express, edit the theme source CSS/Tailwind config, then npm run build:themes, and commit the generated output. Run npm run check:themes in CI and let drift fail the build — this is the difference between a reproducible theme and a hand-edited CSS file that silently diverges from its source.

Runtime switching. The facade exists so you can list available themes and switch at runtime. Keep the switcher thin:

// Livewire component: persist to user preference, then redirect/reload
public function setTheme(string $theme): void
{
    abort_unless(in_array($theme, DaisyUiThemes::available(), true), 422);

    auth()->user()->update(['daisy_theme' => $theme]);
    $this->redirect(request()->header('Referer'));
}

A full page reload after the switch is fine and avoids fighting Livewire's DOM diffing over an <html> attribute.

Integration with an existing Filament theme. If you already use ->viteTheme('resources/css/filament/admin/theme.css'), verify load order: the plugin's published CSS must not be overridden by your own Tailwind build, and you must not double up Tailwind preflight. Confirm on a real page with your custom components, not just a form.

Rollback is a one-liner. Because the plugin is registered declaratively, the fallback is removing/commenting ->plugin(...) and re-enabling Filament's native theme config. Keep that path documented and, ideally, exercised once so you know it works before you need it.

Gotchas and Tips

Stock colors mean assets aren't published. The most common first-run failure. Recovery order: php artisan vendor:publish --tag="filament-daisy-ui-themes-assets", then php artisan filament:assets, then php artisan optimize:clear. If a theme change appears in local but not staging, it's almost always cached or unpublished assets, not a code bug.

Published assets are deployment artifacts. Anything under public/ from vendor:publish must be in your deploy pipeline or re-published on deploy. A vendor:publish --force in the deploy script is safer than committing a vendor-derived directory — but decide once and enforce it, because "worked locally, unstyled in production" is the signature of a half-solved version of this.

Pin the exact version and verify the tag. Adoption signals are thin (5 stars, 0 dependents, one maintainer), and a release date of 2026-10-01 is anomalous — confirm the tag actually exists and what it contains before pinning. composer require osamanagi/filament-daisy-ui-themes:1.1.0 beats ^1.1. Treat the first adopted release as a fork candidate and keep a note of the diff you'd need.

You now own a four-way version matrix. Filament major, daisyUI major, Tailwind version, and Node/npm toolchain all have to move together. Upgrading daisyUI without re-running npm run build:themes leaves theme data out of sync with generated CSS — the panel renders, the colors are wrong. Put npm run check:js && npm run check:themes next to composer test in CI.

CSS specificity is the real integration risk. daisyUI's classes are opinionated about form controls and buttons. If your panel already customizes those, test the interaction explicitly rather than assuming. Symptom to look for: correct palette but wrong borders/focus rings/input heights — that's specificity, not theming.

Dark mode is not prefers-color-scheme. Filament's own dark-mode toggle drives a class on <html>; daisyUI drives data-theme. Confirm which one wins in your setup, and test with the toggle and with OS-level dark mode, plus a hard refresh in between.

Don't scope-creep the package. It styles Filament panels. It does nothing for your public site, emails, or PDFs. If stakeholders hear "branding" and expect the marketing site to change, correct that in the same meeting.

Extension points, in order of preference: config → published views/translations (override under resources/views/vendor/...) → facade → forking. Reach for a fork only if you've already decided you'd maintain it; the code footprint is small enough that a fork is genuinely viable, which is also why the fallback to a hand-written Filament theme using the same daisyUI tokens doesn't waste the palette work.

Named ownership or it rots. No SLA, no security-response commitment, no ecosystem pressure to fix your bug. Assign one owner for upgrades, a CI theme-drift check, and a quarterly review date at adoption time. An unowned UI dependency is what blocks the next Filament upgrade six months later.