- What does solution-forest/filament-scaffold actually generate?
- According to its overview, it reads your existing database schema and generates complete CRUD resources for Filament panels, including Eloquent models, migrations, and Filament resource classes with forms, tables, and relations. The intent is to skip the repetitive boilerplate of wiring a resource to a table and then customize each generated file by hand. The package metadata does not document whether it also emits policies, seeders, factories, or tests, so verify the actual output in a sandbox before assuming coverage.
- How do I install filament-scaffold in a Laravel application?
- Install it with Composer as solution-forest/filament-scaffold inside a Laravel project that already has Filament installed and configured for at least one panel. Because the package description is vague and the README is thin, inspect the source and run php artisan list after installation to discover the actual generator commands and options. Pin an explicit version constraint rather than floating to latest, and record the Laravel, Filament, PHP, and Livewire versions you tested with.
- Which Laravel and Filament versions does filament-scaffold support?
- Supported versions are not clearly stated in the package metadata, which is one of the main evaluation gaps. Check the composer.json constraints in the repository and confirm they match your application's Laravel, Filament, PHP, and Livewire versions before committing to anything. Test in a disposable sandbox first, since an archived package is unlikely to receive compatibility fixes for future Filament majors.
- Is filament-scaffold a runtime dependency or a development-time generator?
- The overview describes a code generator that produces models, migrations, and Filament resource files, which points to development-time use rather than runtime behavior. The recommended pattern is to run it, review and commit the generated files, and treat that code as owned by your application team. Avoid keeping it as a production runtime dependency unless you can justify it, because the package is archived and has no meaningful adoption signal.
- Does the package publish configuration or migration files?
- Publishing behavior is not documented in the available metadata, so you should confirm it empirically after installing. Expect generated migrations to be written into your application's database directory, which means you should run them against a disposable database and read each file before applying it to anything real. Also check for a publishable config file if you need to change naming, paths, or namespace conventions.
- Does filament-scaffold handle relationships between tables?
- The overview explicitly states that generated resources include relations, so foreign keys and common relationship types are likely mapped into Filament form and table components. What is unclear is the depth of that support, for example whether many-to-many pivot tables, polymorphic relations, and custom foreign key naming are handled correctly. Generate a resource against a schema with several relation types and inspect the emitted form and table definitions before trusting it broadly.
- Can I customize the generated Filament resource files?
- Yes, in the sense that the output is ordinary Laravel and Filament code written into your application, so you can edit forms, tables, and relations freely after generation. The tradeoff is that regenerating over an existing file may overwrite your changes, so check whether the command supports force flags or skipping existing files. Committing generated code to version control and treating it as application code is the safest workflow.
- Is filament-scaffold actively maintained and safe for production use?
- The repository is archived, has roughly 63 stars, zero dependents, and shows no obvious production adoption, so treat it as unmaintained upstream with no vendor support. That does not make it unusable, but it does mean no one will fix Filament major upgrades, security issues, or undocumented behavior for you. If the productivity gain is material, plan for an internal fork with a named owner, or restrict usage to internal admin panels and proofs of concept.
- Can I remove the package after generating my resources?
- Because the package emits models, migrations, and resource classes into your application instead of serving them at runtime, removing it after generation is usually feasible. Before uninstalling, verify that no generated file references package namespaces or service providers, and make sure the service provider is not registered in your bootstrap or providers config. Commit the generated code first so you have a clean diff to compare against after removal.
- How should I evaluate filament-scaffold before adopting it, and what are the alternatives?
- Run a time-boxed spike in a sandbox Laravel plus Filament app with pinned versions, generate a representative resource, then review every emitted file, run migrations in a throwaway database, and compare the output against your team's conventions. Check for a test suite and CI in the repository, since none is evident from the metadata, and assign internal ownership before any team-wide rollout. Alternatives include Filament's own make:filament-resource generator commands, hand-written resources for complex domains, or other schema-to-code tools, all of which have clearer maintenance and community support.