Filament Auto Panel Laravel Package

Getting Started

The package generates Filament Resources and Relation Managers from your Eloquent models at panel boot time, so you never run php artisan make:filament-resource for the models it covers. Treat it as scaffolding-as-a-service, not as a replacement for Filament itself.

1. Install (check the README for the exact Filament major it targets — this is a young package and the constraint matters):

   composer require miguilim/filament-auto-panel
   

2. Read the source before the docs. At ~38 stars the README is thin and the src/ tree is small. Open it and find: the service provider, the base Resource class (or trait), and the relation-manager equivalent. That is your real API reference.

3. Publish config if the service provider exposes it:

   php artisan vendor:publish --provider="Miguilim\FilamentAutoPanel\FilamentAutoPanelServiceProvider"
   

4. Wire it into a panel. The two shapes you'll likely find are a plugin registration or a base-class trait. Pick whichever the README shows; the mental model is the same — you hand it models, it hands you resources:

   // app/Providers/Filament/AdminPanelProvider.php
   public function panel(Panel $panel): Panel
   {
       return $panel
           ->id('admin')
           ->path('admin')
           ->login()
           ->plugin(
               AutoPanelPlugin::make()->models([
                   User::class,
                   Post::class,
                   Category::class,
               ])
           );
   }
   

   or the subclass form:

   use Miguilim\FilamentAutoPanel\AutoResource;
   
   class PostResource extends AutoResource
   {
       protected static ?string $model = Post::class;
   }
   

5. First use case: point it at one boring, well-typed model (Post with title, body, status, published_at, category_id) and diff the generated table/form against a hand-written resource. That diff tells you immediately which column types and relations it handles well and which need overrides.

Where to look first, in order: README usage section → the panel provider example → src/ for the base class and any configure* hooks → a quick php artisan route:list | grep admin to confirm routes registered.

Implementation Patterns

Generate-then-graduate. Use the auto resource for the first pass, and the moment a model needs anything bespoke (custom action, computed column, complex form layout), promote it to a normal hand-written Filament resource and remove it from the auto list. Don't try to bend the generator — the escape hatch is writing the resource.

Override, don't fork. The package almost certainly exposes hook methods or closures on the auto resource (configureForm(), configureTable(), modifyQueryUsing()). Subclass the auto resource, override only those, and keep the generated schema for everything else:

class OrderResource extends AutoResource
{
    protected static ?string $model = Order::class;

    public static function configureTable(Table $table): Table
    {
        return parent::configureTable($table)
            ->columns([
                ...parent::configureTable($table)->getColumns(),
                TextColumn::make('total')->money('usd')->sortable(),
            ]);
    }
}

Let casts do the inference work. These generators read DB column types and Eloquent casts to decide column/form components. Your job on day one is to make the model honest:

protected $casts = [
    'published_at' => 'datetime',
    'is_featured'  => 'boolean',
    'status'       => PostStatus::class,   // enum → Filament Select
    'meta'         => 'array',             // JSON column
];

Without the enum cast you get a plain text input; with it you get a proper select.

Relation managers as a discovery layer. Auto relation managers are the highest-value part for admin panels: attach them to a parent model and get posts, comments, roles for free. Use them for read-mostly inspection (list a user's orders) and hand-write the ones with business logic (attaching roles with side effects).

Pair with policies, per model. Auto-generation does not mean auto-authorization. Create policies (php artisan make:policy PostPolicy --model=Post) for every model you expose. Filament will still call viewAny, create, update, delete — a missing policy plus a permissive Gate::before is how you ship an admin panel where every editor can delete everything.

Tenancy. If the panel is tenanted (->tenant(Team::class)), verify scoping explicitly with two accounts before trusting it. Runtime-generated resources query the model directly, and tenant scoping is exactly the kind of thing a generic generator can miss.

Config-driven model list. Keep the model list in a config file rather than the panel provider, so you can toggle resources per environment (auto-generate everything in local, a curated subset in production):

// config/filament-auto-panel.php
return [
    'models' => env('APP_ENV') === 'local'
        ? 'auto-discover'
        : [User::class, Post::class, Order::class],
];

Gotchas and Tips

Empty table = silent failure. When introspection fails (unrecognized column type, missing model, mis-registered class), you usually get an empty or partially rendered table, not an exception. If a resource doesn't appear: check route:list, then dd() the model list in your panel provider, then confirm the resource is registered via the panel's resource collection.

N+1 is the default. A generated table with a category.name column will lazy-load per row unless the package eager-loads. Add it yourself:

->modifyQueryUsing(fn (Builder $q) => $q->with(['category', 'author']))

Watch barryvdh/laravel-debugbar on any index page with >50 rows — that's where this bites.

Column inference is a guess. Nullable strings become TextColumn::make(...)->placeholder('—'); boolean columns become toggles; date columns become date pickers. Any column where the DB type is lossy (e.g. VARCHAR storing currency, TEXT storing JSON without a cast) will render wrong. Fix it at the cast level, not by overriding the component.

Policy checks still run. canViewAny, canCreate, etc. are evaluated against the auto-generated resource the same as a normal one. If you see 403s on a fresh auto resource, that's the policy layer working correctly — write the policy.

Global search. Dynamic resources often skip getGloballySearchableAttributes(), so your cmd-K search silently returns nothing for those models. Verify and override if needed.

Route caching and optimize. Because resources are constructed at runtime, run php artisan filament:optimize (and route:cache) and re-test before deploying. If the package relies on discovery that runs outside the cache path, resources can vanish in production only. This is worth a dedicated test.

Pin the version. 38 stars, zero dependents, first release window in 2026 — the API can shift between minors. Pin exactly and use composer update --dry-run before touching Filament:

"miguilim/filament-auto-panel": "1.0.*"

Wrap it once. Create your own App\Filament\AutoResource extending the package class and have everything extend that. If the package is abandoned or you outgrow it, migration is a single file plus a find-and-replace rather than a hunt through every resource.

Test the generated surface. Feature-test each auto resource's index and create pages with actingAs():

it('renders the posts resource', function () {
    $this->actingAs(User::factory()->admin()->create())
        ->get(PostResource::getUrl('index'))
        ->assertOk();
});

These tests catch the silent failures — a removed cast, a renamed column, a broken relation — that a generator will happily produce and that no exception will flag.

Extension points to look for in src/: the column/form resolver (where type inference lives), any register() hook on the plugin, and the base relation-manager class. Those are the three places worth subclassing; everything else is Filament's own API and you should use it directly.