Filament Command Palette Laravel Package

Technical Evaluation

Architecture fit A Filament panel plugin registered in the panel provider. No migrations, no schema, no persisted state, no separate JS build — it rides Filament's existing Alpine/Livewire bundle and inherits panel theming and dark mode. The entire public surface is small: roughly six config keys plus a CommandItem value object with a fluent builder. That is the right shape for an admin-UX enhancement: additive, reversible, and cheap to evaluate.

Integration feasibility Two steps to first value (composer require, one line in panel()), one optional step to configure (vendor:publish --tag=command-palette-config). Custom commands are closures returning CommandItem[]. There is nothing here that requires a database change, a queue, a cron, or an infrastructure decision — which is exactly what makes it safe to trial.

Technical risk

• Bus factor. One maintainer, 19 stars, zero dependents. There is no ecosystem validation behind this package. Treat it as a well-scoped utility, not a platform commitment.
• Filament major-version coupling. v5 today (v4 support added in 1.1). Filament v6 will likely strand this package for some window. The plugin becomes a constraint on our own upgrade path, not just a feature.
• Closure-in-config is a production trap. The README's custom_commands example puts PHP closures in config/command-palette.php. php artisan config:cache cannot serialize closures — custom commands vanish silently in production while working perfectly in dev. This is the single most likely way this package fails for us.
• Authorization is not the palette's job. It lists whatever the closure returns. Unauthorized users see entries, click, and get a 403 — bad UX plus a small information-enumeration leak. Gating must happen at generation time.
• README overstates capability. The description claims fuzzy search across "navigation, records and actions," but the feature list only substantiates pages, resources, and navigation items. Record-level search must be verified before it appears in any stakeholder-facing plan.
• Published views are a fork. resources/views/vendor/command-palette/ stops receiving upstream changes the moment we publish; 1.4 explicitly reworked templates, so any pre-1.4 customization is already divergent.
• Global, not per-panel config. template and max_results are single config keys. Multiple panels with different audiences cannot be styled independently.
• Release metadata looks unreliable. The last release is dated in the future. Treat observed cadence and responsiveness as unverified until we look at the commit history directly.

Key questions

1. Does the maintainer respond to issues and merge PRs within a window we can tolerate, and is there any funded roadmap?
2. Does record-level search actually exist, or is this navigation-only? Verify against a live panel before scoping it.
3. How does it interact with Filament's built-in global search — duplicate control surface, or genuine complement?
4. What is our Filament upgrade cadence, and can we absorb a plugin gap during v6?
5. Is the target panel internal-only or customer-facing? This single answer drives our entire risk tolerance.
6. Do we have any way to measure palette adoption, or are we shipping on vibes?

Integration Approach

Stack fit Laravel 11/12 (13 via 1.3), PHP 8.2+, Filament v4/v5. Aligns cleanly with a modern Filament admin panel. No new runtime dependencies, no queue workers, no storage.

Migration path None required. There is no data migration, no backfill, no cutover window — the palette is a UI layer over routes that already exist. The removal path is equally clean: delete the plugin line, delete the command class, delete the config file. That reversibility is the primary reason to trial it rather than build it.

Compatibility Pin the package version in composer.json rather than floating. Confirm our Filament version against the release notes (v4 vs v5 support arrived in different releases). Check whether published views exist in the codebase before any minor upgrade — if they do, that upgrade becomes a manual merge.

Sequencing

1. Register on one internal admin panel with zero custom commands. One line. The out-of-the-box value — jumping to any page, resource, or nav item on a deep sidebar — is real and costs nothing to measure.
2. Instrument for two weeks. Count palette opens, command selections, and empty-result searches. This is the go/no-go input for everything below.
3. Extract command generation into an invokable class rather than an anonymous closure, and register it via Config::set() in AppServiceProvider::boot() — never in config/command-palette.php. This makes the commands unit-testable and makes removal a one-file deletion.
4. Gate every command by permission inside the closure, using auth()->user()?->can() at generation time. Do not cache the resulting array across users.
5. Harden for production. include_publish_views_command => false — there is no reason to ship a developer tool to end users. Consider show_topbar_button => false on internal panels where the shortcut alone suffices; keep it on for discoverability on broader audiences. Add a CI step that runs config:cache then config:clear and asserts commands still resolve.
6. Defer templates and view publishing. Stay on standard until a concrete styling requirement exists. preview looks best in a demo and costs the most to maintain — every command you care about needs description() and preview() metadata or the detail pane reads as a stub.

Operational Impact

Maintenance Small footprint, but we own the glue: the command class, the provider wiring, the permission logic. Pin the version, subscribe to releases, and treat any published views as a fork with a re-merge cost at every upgrade. Budget a periodic review of whether the package is still alive before our next Filament major.

Support Community-only, no SLA, single maintainer. However, the surface area is genuinely small — a plugin class and a view set. If the package is abandoned, forking is an afternoon, not a project. That asymmetry materially lowers the support risk and should be stated explicitly when this goes to a review.

Scaling Closures execute per request. Static arrays are free; per-command database lookups are not, and a poorly written closure turns every admin page load into N queries. If commands must be data-driven, cache per-user with a short TTL — never cache across users, or permissions leak between sessions. max_results (default 10 per category) caps payload size, which matters more on wide permission sets than on large tables.

Failure modes

Ramp-up Developer: roughly an hour to first working palette, half a day to a gated, tested, production-grade custom command set. End user: near zero — Cmd+K is an established idiom. The real ramp-up question is discoverability, which is precisely what the topbar button toggles; ship it on first, then measure whether the keyboard shortcut carries the load alone.

Recommendation for the TPM Trial on one internal panel, instrumented, with zero custom commands and a two-week measurement window. Proceed to custom commands only if the invocation data justifies the integration glue we'd then own. The decision to adopt is cheap and reversible; the decision to build a command layer on top of it is neither, and should be gated on evidence.