- How do I install filament-sensible-defaults in a Laravel project?
- Install it with Composer using composer require jeffersongoncalves/filament-sensible-defaults, publish the config file with php artisan vendor:publish, and register the package plugin in each Filament panel provider where you want the defaults applied. There are no migrations, environment variables, queue workers, or external services to configure. Budget roughly half a day to a day, including a visual pass over representative resources.
- Can I use filament-sensible-defaults on an existing Filament panel?
- Yes. The package registers boot-time configureUsing-style defaults on Filament component classes, so it layers onto existing panels rather than replacing your resources or pages. Because every block and sub-item is toggleable, you can adopt only the opinions you agree with. Treat adoption as accepting a baseline with documented exceptions rather than ceding design authority to a third-party package.
- How do I disable one default without turning off the whole block?
- In version 1.1.0 the config uses fine-grained sub-arrays, so you can keep a block enabled and opt out of a single behaviour, for example setting delete_action to false while the rest of action_defaults stays active. This is what makes partial adoption practical instead of all-or-nothing. Check the published config file for the exact key names in each block.
- What happens if a block is set to false but its sub-items are true?
- Block-level false acts as a master switch: it disables every sub-item in that block regardless of the individual settings. This precedence is documented and keeps rollback reasoning simple. If you want most of a block, leave the block enabled and turn off only the specific keys you disagree with.
- Which Laravel and Filament versions does the package support?
- Version constraints live in the package's composer.json, and the package hooks Filament's component configuration APIs, which change across majors. Before installing, confirm the constraint matches your Filament major, then pin both Filament and the plugin version. Because these registrations can silently stop firing after a Filament upgrade, pinning plus a render smoke test is safer than floating constraints.
- Is filament-sensible-defaults safe to use in production?
- It is a small MIT-licensed configuration layer with no models, migrations, routes, or jobs, so the blast radius is limited to presentation defaults. The main concern is maintenance: it currently has a single maintainer, very few stars, and no dependents, so treat it as a utility rather than a supported dependency. Pin the version and keep the one-line removal path, dropping the Composer package and the plugin registration, documented in your notes.
- How do I test that the defaults are still applied after a Filament upgrade?
- Add a render smoke test for each block you rely on, asserting that a representative resource or form renders with the expected behaviour. That way a renamed Filament class or method fails in CI instead of silently degrading the UI. This matters because the registrations can no-op rather than throw when the underlying API changes.
- Does it work in multi-panel Filament applications?
- Boot-time component configuration is process-global, so the defaults apply across panels unless you override them per panel. Resolution also depends on registration order relative to other plugins and your own configureUsing calls. In multi-panel apps, expect occasional investigations into why a field behaves differently, and document your per-panel overrides.
- How is this different from building my own base Resource or design system?
- If you already have an in-house base Resource or Page layer, or a formal design system with brand tokens, this package becomes a second source of truth and the question of which layer wins turns into recurring debugging. If you do not, it converts scattered implicit conventions and code-review nitpicks into one version-controlled config file. The package is explicit that its defaults are opinionated and overridable per panel.
- Does it add runtime overhead or database changes?
- No. Configuration is applied at boot time through Filament's configureUsing-style hooks, and there are no migrations, queue workers, env vars, or external services. The cost is configuration resolution at boot plus the ongoing overhead of maintaining the defaults you accept.