jeffersongoncalves/filafluxkitv5
FilaFluxKit v5 is a Laravel package that combines Filament with Flux UI to provide prebuilt admin layouts, reusable components, and starter resources, helping you build polished back-office interfaces faster while keeping configuration simple and customization open for rapid Laravel admin developmen...
This is a starter kit, not a package you composer require into an existing app. You adopt it at project creation and own the code from day one. There is no upstream composer update path for the scaffolding itself.
Scaffold the project. Either clone the repo and composer install && npm install, or use the Laravel installer's --using flag:
laravel new my-app --using=jeffersongoncalves/filafluxkitv5
Confirm the exact invocation against the repo README before relying on it — starter kits vary in whether they ship as an installer-compatible template.
Read these first, in order:
composer.json — pins for laravel/framework, filament/filament, livewire/flux, jeffersongoncalves/filament-flux. These tell you how bleeding-edge the kit is and whether you can safely add other packages.app/Providers/Filament/*PanelProvider.php — the Admin/App/Guest panels live here. This is where 80% of your day-to-day customization happens.config/auth.php — the multi-guard setup (guards, providers, password brokers). Misreading this is the #1 source of "why am I logged out" bugs.routes/web.php and each panel's ->routes() — panel routing, login paths, and redirects.app/Models/User.php and any second auth model — who logs into which panel.First real use case: split back-office from customer-facing. The kit's shape maps cleanly onto an internal admin (/admin, admin guard) plus a customer portal (/app, web guard) plus a public marketing/guest area. Log in as the seeded admin, hit /admin, then hit /app with a non-admin user and verify the guards are actually isolated before you write any feature code.
Baseline check before building: php artisan about, php artisan route:list --path=admin, and a fresh npm run build. If the three panels don't render after a clean install, fix that first — you do not want to discover a broken Vite/theme build three features in.
Customize through panel providers, not by editing vendor internals. Each panel provider is a fluent configuration object:
public function panel(Panel $panel): Panel
{
return $panel
->id('admin')
->path('admin')
->guard('admin')
->login()
->colors(['primary' => Color::Indigo])
->discoverResources(in: app_path('Filament/Admin/Resources'), for: 'App\\Filament\\Admin\\Resources')
->discoverPages(in: app_path('Filament/Admin/Pages'), for: 'App\\Filament\\Admin\\Pages');
}
Keep resources/pages namespaced per panel (Filament/Admin, Filament/App) rather than sharing one directory. Shared resources across guards are possible but quickly become a permissions tangle.
Multi-guard integration. Three rules that save hours:
auth:admin middleware, Auth::guard('admin')->user(), and Filament::auth()->user() inside panel code.config/auth.php. Password resets silently break when brokers point at the wrong provider.->default() on exactly one panel (usually Admin) so bare / redirects and Filament::getDefaultPanel() are deterministic.Auth redirects. After login, Filament sends users to the panel's home. If you need custom destinations (e.g. customers to a dashboard, admins to a resource index), use the panel's ->login() + a redirect callback or a small middleware rather than overriding the login page. Logout redirects are configured per panel — set them explicitly, because cross-guard logout that lands on another guard's login page is a common polish gap.
Flux UI usage. The filament-flux plugin bridges Livewire Flux components into Filament views. The practical pattern:
->plugin(FilamentFluxPlugin::make())) if the kit hasn't already done so, and only on the panels that need it.Workflow for a new feature. Pick the panel → create the resource/page inside that panel's namespace → wire authorization via policies that check the guard-appropriate model → add a Pest/PHPUnit test using actingAs($user, 'admin'). The guard argument in tests is the single highest-leverage habit with this kit.
Tenancy. Not claimed by the description. If you need Filament tenancy, plan to add it yourself; don't assume the Guest/App/Admin split gives you tenant scoping.
composer.json constraints before adding; expect to use --with-all-dependencies and occasionally a dev branch.Auth::user() can be the wrong user depending on context. In Blade, prefer auth('admin')->user() over auth()->user(). In middleware, always name the guard.config/auth.php passwords.<guard> pointing at the wrong provider. Check password_reset_tokens assumptions too.php artisan filament:cache-components (if enabled) and php artisan optimize:clear. Stale component caches produce "class not found" or missing-page symptoms that look like code errors.->viteTheme() registration. If one panel looks unstyled after npm run build, check the theme path and that the panel references the right build asset.admin, app, and a guest panel with / or overlapping slugs will fight. Run php artisan route:list and confirm ordering; give the guest panel an explicit low-priority path or rely on ->default() semantics deliberately.php artisan about (environment sanity), php artisan route:list --path=<panel>, and Filament::getCurrentPanel() dumped in a page's mount() to confirm which panel is resolving.Page classes, policies, and a service provider of your own. Avoid editing files under vendor/jeffersongoncalves/ or Filament's published internals — you'll lose them on the next composer update.composer.json, run the kit's test suite (if present) plus your own auth tests for all three guards, and audit the seeded users/credentials that ship with the scaffold.How can I help you explore Laravel packages today?