Filakit Laravel Package

Getting Started

Filakit is a Filament v3 application starter kit: it gives you a Laravel app shell, an authentication flow, and a pre-wired Filament panel so you can start building admin screens without hand-rolling the scaffolding.

Minimal steps:

composer create-project jeffersongoncalves/filakit my-app
cd my-app
npm install && npm run build
cp .env.example .env && php artisan key:generate
php artisan migrate --seed
php artisan serve

Then hit /admin (or whatever the panel path resolves to in your AdminPanelProvider) and log in with the seeded credentials.

Where to look first, in order:

1. app/Providers/Filament/*PanelProvider.php — this is the single most important file. Path, middleware, auth guard, colors, and discovered resource directories are all declared here.
2. app/Models/User.php (and any admin model) — check the FilamentUser contract and canAccessPanel() implementation before assuming who can log in.
3. app/Filament/Resources/ — the resource directory structure tells you the conventions the kit expects you to follow.
4. config/ and the package's own published config — anything the kit overrides from upstream Filament lives here.

First use case: rather than building a CRUD screen from scratch, copy an existing resource and rename it. The kit's value is in the working example, not in the framework underneath — Filament itself is thoroughly documented upstream, so spend your reading time on the kit's opinionated layer.

Implementation Patterns

Resource-first development. Generate with php artisan make:filament-resource Post --generate and then prune. The kit's existing resources are the reference for how forms, tables, and relation managers are laid out; deviating from that shape means fighting discovered-path registration and policy assumptions later.

Panel providers as the extension seam. Need a second panel (e.g. a customer-facing /app alongside /admin)? Don't modify the existing provider — create a new one with php artisan make:filament-panel customer. The kit's auth wiring assumes one panel, so a second panel needs its own guard, its own canAccessPanel() logic, and its own login route.

Authorization. Filament resources are policy-driven. Register policies explicitly and don't rely on the absence of a policy meaning "allow" — in production that becomes an accidental permission grant. If the kit ships roles/permissions, treat the seeders as a starting taxonomy, not a schema.

Widgets over custom dashboards. The dashboard is composed of widgets registered on the panel. Adding a stats widget is a two-line registration plus a StatsOverviewWidget subclass; building a custom Blade dashboard is almost always unnecessary work.

Localization. Filament reads config('app.locale') and per-panel ->locale(). If you ship multi-language, set it per panel rather than globally so admin tooling stays in one language while the app front-end switches per request.

Deployment. Run php artisan filament:optimize (or the equivalent cache commands in your version) as part of deploy, alongside config:cache and route:cache. Cache Filament assets in CI, not on the production box.

Gotchas and Tips

3.3.56 restructured model/resource/login ownership. PR #197 ("Use user/admin packages for models, resources and login") moves the User/Admin models, Filament resources, and the login page out of the kit and into separate packages. If you are upgrading from 3.3.55:

• Re-publish or diff the app/Models/ tree — your local User model may now conflict with, or be superseded by, a package-provided one.
• Any customization you made to the login page (view overrides, ->login() on the panel, custom authenticateUsing) may no longer be picked up.
• Namespaces for resources and models may have changed. Run composer dump-autoload and clear filament:optimize caches before concluding something is broken.
• If you have a subclassed User model with app-specific traits, verify the class still extends the right parent after the upgrade.

The rest of 3.3.56 is dependency bumps and CI housekeeping (Dependabot groups, pnpm overrides for shell-quote/source-map-js, PHPStan on PHP 8.4). Those carry no migration burden for consumers, but the PHP 8.4 CI target is a signal that PHP 8.4 is supported — check it against your own CI matrix if you were holding back.

Panel access silently denies. A user who authenticates successfully but sees a 403 on /admin is almost always failing canAccessPanel() or the FilamentUser contract. Filament intentionally does the check at the panel level, not at the guard, so Auth::attempt() succeeding tells you nothing about panel access. Log the result of canAccessPanel() when debugging.

php artisan optimize:clear is your first move. Stale config, cached routes, and cached Filament component registrations cause the majority of "my new resource doesn't appear" reports. Cached views are a separate command — if a Blade override isn't taking effect, view:clear before you start editing anything.

Publishing is not merging. vendor:publish overwrites. Publish Filament's config/views once, commit the result, and thereafter treat the package as read-only — otherwise a future composer update plus a careless publish will silently discard your customizations.

Asset builds are a separate pipeline. Filament ships its own CSS/JS, but any custom theme you register requires you to build and reference a compiled stylesheet through the panel's ->viteTheme(). Deploying without running the front-end build gives you an unstyled but functional panel — easy to miss in a Docker deploy that only runs composer install.

Extension points worth knowing: custom form/table components, Filament::registerRenderHook() for injecting markup into panel chrome, custom pages extending Filament\Pages\Page, and macros on the schema/table builders. Prefer render hooks and macros over view overrides — overrides break on minor Filament bumps, hooks generally don't.

Pin your versions. Filakit tracks Filament closely (3.3.56 here mirrors Filament 3.3.56). Because the kit's release cadence is dependency-driven, pinning filakit to a minor range and reviewing changelogs on bump is cheaper than debugging a surprise architectural change like the 3.3.56 package split mid-sprint.