Filament Starter Kit Laravel Package

Getting Started

This is a v0.0.1 skeleton for a Filament panel, not a stable utility library. Treat the first hour as reconnaissance, not integration.

1. Read the repo before requiring it. Since the release is explicitly flagged Non Production Ready, the source tree is the documentation. Look at, in order:

   • composer.json — the actual require constraints (filament/filament major version, PHP version, Laravel version) tell you more about compatibility than any README will at 0.0.1.
   • src/ and app/ — where the panel provider lives, and whether it's a package provider or an application skeleton.
   • database/migrations and database/seeders — a starter kit's value is almost entirely in its schema and seed data.
   • config/ — anything publishable.

2. Decide which delivery model you're consuming. Starter kits ship in one of two shapes and they are not interchangeable:

   • Application skeleton (clone/fork the repo, composer install, php artisan migrate --seed). Most filament-starter-kit style repos are this. You do not composer require it into an existing app.
   • Installable package with a service provider and vendor:publish tags. If there's no extra.laravel.providers in composer.json, it's the former.

3. Install in a throwaway directory first. Fresh Laravel app, or a git clone into /tmp. Run the migrate/seed path end to end and open the panel. Confirm you can log in. Only then point it at a real database.

4. First real use case: stand up an authenticated admin panel with a user model and one resource, so you can evaluate the conventions (resource structure, form/table schema style, policy wiring) before committing your team to them. If those conventions don't match your codebase, the kit costs more than it saves.

Implementation Patterns

Fork-and-own, don't track upstream. At 0.0.1 there is no upgrade path. Clone once, remove origin, and treat the code as your own. Attempting to composer update this later will either do nothing or produce conflicts against Filament's own minor releases.

Diff the generated schema against your own. Starter kits encode opinions in migrations — UUID vs auto-increment, soft deletes everywhere, a roles table shape. Run php artisan migrate --pretend and read the SQL. Retrofitting primary key types after seeding is painful.

Panel provider as the integration seam. Almost all customization routes through the panel provider's fluent chain (->colors(), ->navigationGroups(), ->middleware(), ->login()). Keep your edits to that file in one commit so upstream comparisons stay readable.

Resource scaffolding over hand-writing. Once the panel boots, use php artisan make:filament-resource Model --generate and let the kit's existing resources act as the style reference. Copy the kit's form/table idioms rather than inventing new ones — consistency is the whole point of adopting a kit.

Seeders as fixtures, not as production data. Split the kit's seeders: keep role/permission and reference data, extract demo users and sample content into a local-only seeder guarded by app()->environment('local'). Starter kits routinely seed an admin account with a hardcoded password.

Auth boundary is the integration point for existing apps. If you're grafting Filament onto an existing user table, you need the FilamentUser contract (canAccessPanel()) on your model plus panel guard configuration. The kit's version of this is written against its own User model — re-implement it for yours rather than copying the model wholesale.

Wrap it in your own service layer early. If the kit touches anything you'll later swap (permissions backend, media library, settings store), put your own interface in front of it in week one. Filament-ecosystem packages (Shield, Spatie Permission, Curator) are the usual suspects and they change majors often.

Gotchas and Tips

• The version number is the headline. v0.0.1 plus an explicit "Non Production Ready" marker means: no BC promise, possibly no tests, possibly no license file check. Verify LICENSE exists and is compatible with your use before it reaches a client repo.

• Pin Filament exactly in composer.json. Filament ships breaking changes in minors. A starter kit written against ^3.x today may not boot against a later 3.x. Commit composer.lock and treat Filament upgrades as planned work with a test pass.

• Stub and publish collisions. If you vendor:publish from this and from Filament itself, you'll overwrite panel providers or config. Publish Filament's own assets and config first, then layer the kit on top, and read every --force prompt.

• Vite/npm is a common silent failure. Starter kits often assume a built asset manifest. If the panel renders unstyled, run npm install && npm run build before debugging PHP. Check vite.config.js for a custom input path that doesn't match your setup.

• Storage link and media. php artisan storage:link is not run by migrations. Avatar/file upload features will 404 silently until you do.

• Debugging panel boot failures: php artisan about confirms the provider registered; php artisan filament:about (or the panel's route list via php artisan route:list --path=admin) confirms the panel mounted. A white screen at /admin is almost always a provider not in bootstrap/providers.php or a guard misconfiguration.

• Config caching hides provider issues. If behavior differs between php artisan serve and a deployed environment, run php artisan config:clear && php artisan optimize:clear before assuming a code bug.

• Extension points to note while reading: the panel provider (middleware, auth guard, path), the User model's FilamentUser implementation, policy auto-discovery in app/Policies, and any Macroable/render-hook usage. These are where customization belongs; editing vendor Filament views is a trap.

• No upgrade path exists yet. Because there's no prior release and no changelog beyond a commit range, you cannot assess churn. Re-evaluate when a 0.1.x or 1.0 lands with a real changelog — until then, budget for the kit being a one-time scaffold rather than a maintained dependency.