Filament Sensible Defaults Laravel Package

Getting Started

Install and wire up (about 10 minutes):

composer require jeffersongoncalves/filament-sensible-defaults
php artisan vendor:publish --tag="filament-sensible-defaults-config"

Then register the plugin on the panel(s) you want it to touch, in the relevant PanelProvider:

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(\Jeffersongoncalves\FilamentSensibleDefaults\FilamentSensibleDefaultsPlugin::make());
}

Pin the version rather than floating it — "jeffersongoncalves/filament-sensible-defaults": "1.1.0" — and confirm the exact plugin FQCN and supported Filament range against the README before you commit. With 2 stars, 0 dependents and a single maintainer, the README is the spec, not a guarantee.

Where to look first, in this order:

1. config/filament-sensible-defaults.php — this is the entire public surface of the package. Read it top to bottom before enabling anything; it is effectively the changelog of opinions you're buying.
2. The package's service provider (vendor/jeffersongoncalves/filament-sensible-defaults/src/...) — every default is a configureUsing call. Ten minutes here tells you exactly which Filament classes you're mutating, which is the only reliable map when something behaves oddly later.
3. README → "Fine-grained control" — the list of sub-arrays (actions, select, datetime, repeater, form, page, table) added in 1.1.0.

First use case — the one that pays for itself immediately: pick your busiest conventional CRUD resource (the one with twenty similar list/create/edit screens behind it). Enable the plugin, open list + create + edit, and screenshot before/after. That single resource is usually enough to see whether the package's opinions match your house style — action button grouping, form layout, select behaviour, date formats, table density — or whether you'd spend your life writing opt-outs.

The safe rollout (recommended for anything already in production): publish the config with every block set to false, enable one block at a time in a feature branch, and diff screenshots per block. Reversibility is the package's best feature — flipping a boolean restores prior behaviour, and removing the plugin entirely is a one-line change plus a composer remove.

Implementation Patterns

Baseline-everywhere (the intended pattern). Register the plugin on every panel and treat the published config as your UI standard. The day-to-day win is negative work: new Resources and Pages inherit the baseline without a single line of per-resource configuration, and code review stops being the enforcement mechanism for button ordering and date formats. If you run multiple panels, this is also the pattern that kills per-panel drift.

Pilot-one-panel. Because registration is per PanelProvider, you can enable it on an internal ops panel and leave customer-facing panels untouched. Use this to get design sign-off with real screens instead of config diffs, then roll out.

Fine-grained opt-outs over block-offs (1.1.0). This is the single most useful change for real adoption. Instead of disabling all of action_defaults because you hate one thing about delete buttons:

'actions' => [
    'action_group' => true,
    'action'       => true,
    'create_action'=> true,
    'edit_action'  => true,
    'delete_action'=> false, // opt out just this one
    'view_action'  => true,
],

Keep the block master switch true and carve out the individual offender. The pattern to adopt as a team rule: block booleans off only when you reject the whole concept; sub-item opt-outs for everything else. That keeps you on the upgrade path with the smallest possible divergence.

Layering with your own base classes. If you already have BaseResource / BasePage classes, don't fight the plugin — let it set the global baseline, then re-apply your exceptions per class via Filament's own configureUsing in a service provider that boots after the plugin. Registration order wins, so keep all your overrides in one provider and register the plugin earlier. If you find yourself writing more override lines than the plugin saves, that's the signal to drop the plugin and own the whole layer.

Smoke test as a tripwire. Add one test that boots a panel and renders a page exercising each enabled block (an actions column, a form with a select + date picker + repeater, an infolist/table). Filament major upgrades tend to make this package silently no-op rather than crash — a rename means the configureUsing call never fires — so the test's job is to fail loudly on a visual/component assertion, not to check for exceptions. Run it on every composer update.

Config as a deployment artifact. The config file is version-controlled and cache-compatible like any Laravel config. Treat changes to it as reviewable design decisions: a diff in this file should be as scrutinised as a migration.

Exit plan, documented up front. If you later move to an in-house implementation, the published config file is the migration artifact — copy it into your own provider and reimplement the corresponding configureUsing calls. Worth writing that sentence into the ADR on day one so nobody treats this as load-bearing infrastructure.

Gotchas and Tips

• Master switches beat sub-items, always. Setting 'delete_action' => true inside 'actions' does nothing if the block-level boolean is false. This is the #1 cause of "my opt-out/opt-in isn't working." Debug order: block boolean first, sub-array second.
• Silent degradation is the failure mode. The package hooks Filament's component configuration, which is the most churn-prone surface across Filament majors. A renamed class or method means registrations simply never fire — no exception, no log line, just subtly inconsistent UI that shows up in a design review three weeks later. Pin Filament, pin this package, and run the render smoke test on every upgrade.
• Global process state and "spooky action at a distance." Boot-time configureUsing is process-global. Other plugins and your own providers also call it, and resolution depends on registration order. When a component behaves unexpectedly, don't start in your Resource — grep both your providers and vendor/ for configureUsing on that class and work out which registration ran last.
• Test-suite contamination. Static configuration persists for the life of the process, so component-state assertions can behave differently under parallel test execution or long-running workers. If you hit this, isolate the panels that use the plugin into their own test suite rather than chasing it globally.
• Config cache. Edits to the published config do nothing until you php artisan config:clear (locally) or re-cache (config:cache) in deploy. Given the whole package is configuration, a stale cache looks identical to a broken package.
• vendor:publish --force overwrites your tuning. Once the config has local edits, keep a copy under version control and diff the upstream version on upgrade rather than blindly re-publishing.
• Locale and display formats are opinions, not facts. The datetime and display-format defaults bake in formatting choices. If you run multi-locale panels or have brand/accessibility requirements around date formats or table density, verify those blocks specifically before enabling — this surfaces as review churn, not as a bug.
• Blast radius is small; supply chain isn't. No migrations, no assets, no queues, no runtime services — removal is under a day. But 2 stars and one maintainer means no support expectation: vendor or fork it, lock the version, and know that a security disclosure path likely doesn't exist.
• Know when to stop. If you've disabled more than a handful of defaults, the package has become a competing source of truth with your design system. That's the moment to lift the accepted subset into your own small provider — roughly a day of work either way, which is exactly why adopting this first is a low-regret way to find out where your team actually stands on each opinion.