Filament Resource Generator Laravel Package

Getting Started

This package is a scaffolding accelerator: it generates a whole Filament CRUD "module" (model, migration, factory, seeder, and admin resource) from one artisan command. Treat it as a one-time code generator you run during development, not a runtime dependency.

Minimal setup:

composer require intcore/filament-resource-generator --dev

Because adoption is very low (10 stars, 0 dependents), verify compatibility with your installed Filament major version before committing. The package ships an artisan command (or commands) — discover them rather than guessing the signature:

php artisan list | grep -i filament

Publish config and stubs so you can inspect and override what gets written:

php artisan vendor:publish --provider="Intcore\FilamentResourceGenerator\...ServiceProvider"

The README in the repo is the authoritative source for exact command names, flags, and field syntax — read it first, then confirm the command's --help output matches what it describes.

First use case: pick one simple entity you'd normally scaffold by hand (e.g. Post with title, slug, body, published_at). Run the generator, then diff the output against what you would have written. This tells you in five minutes whether its conventions match your project, before you trust it on ten models.

Implementation Patterns

Scaffold-then-refactor. Generate a module, immediately review the output, and hand-edit from there. Generated code is a starting point, not something you keep regenerating. This is the pattern that matches how the package is intended to be used for a "complete module."

Field-driven definition. Most generators of this type take a field list (name:type or a fluent builder) and map each type to a migration column, a form component, and a table column. Confirm the mapping table in the README — that mapping is where most of the value lives, and where most surprises happen.

Batch a domain in one sitting. Since it generates model + migration + factory + seeder + resource together, the highest-leverage workflow is to define several related entities at once, review the migrations for foreign-key and index consistency, then run php artisan migrate and migrate:fresh --seed in one pass.

Fall back to Filament's native commands for incremental work. Once a module exists, add relationships or extra fields using php artisan make:migration and hand-edited resource files rather than re-running the generator. Mixing generated and hand-written code is fine; re-running the generator over hand-written code is not.

Pair with factories/seeders for immediate feedback. The generated factories and seeders exist to let you populate the admin panel and click through the resource right away. Use them to validate that form/table definitions actually render before you wire real business logic.

Keep it out of production dependencies by installing with --dev and requiring it only on developer machines, so a stale generator can't affect deploys.

Gotchas and Tips

• Overwrite risk is the big one. Generators typically write file paths derived from the model name. Any existing file at that path may be silently overwritten or cause a hard failure depending on the package's behavior. Commit or stash before every run, and check whether a --force/--dry-run flag exists before you need it.
• Filament major-version drift. The Filament admin resource API changed meaningfully between majors (component namespaces, form(Form $form) vs form(Schema $schema), table API). With only 10 stars and no dependents, expect the package to track one Filament version. Read the package's composer.json require block and pin it; don't let composer update silently move it.
• Command namespace is uncertain. Don't trust a guessed command name. Run php artisan list, then php artisan <command> --help. If --help and the README disagree, trust --help — it's the code you actually have.
• Migration collisions. If a table already exists (or a migration with the same timestamp prefix was generated in the same second), migrations can run out of order or conflict. Review the generated migrations/ entries before running; adjust timestamps if needed.
• Stubs are the real extension point. Publish them and edit the published copies. This is how you make generated resources match your project's conventions (base classes, traits, policies, enum casts) instead of post-editing every file. Prefer this over fighting the generator on each run.
• Low adoption means you are the QA. Read the generated migration and resource code line by line the first few times. Look specifically for missing nullable(), absent foreignId()->constrained() on relationship fields, and table columns that don't match the form fields — those are the common generator slips.
• Debugging a failed generation: run with verbose output (-vvv), check storage/logs/laravel.log, and confirm the target directories are writable and match where Filament actually discovers resources (app/Filament/Resources by convention — but confirm against your PanelProvider). A generator writing to the wrong path produces silently "missing" modules.
• Don't build on it architecturally. With 0 dependents, treat this package as disposable. If your workflow depends on it, that dependency is on you to maintain — copy the published stubs and any useful logic into your own repo once it proves worth keeping.