Filament Spotlight 2 Laravel Package

Technical Evaluation

Package context. jeremykenedy/filament-spotlight-2 is a Filament v2 admin-panel plugin that adds a Spotlight-style global search/command palette (Livewire component + Blade view + publishable assets). It is a UI convenience layer over existing Eloquent resources — no schema changes, no separate datastore, no background workers.

What v2.0.1 actually contains. Every entry in the changelog is a Dependabot bump of JavaScript build-time dependencies (webpack, postcss, @babel/traverse, axios, loader-utils, json5, browserify-sign, ip, async). There are no PHP source changes, no config changes, no new features, no deprecations, and no migrations. The PRs are dated across late-2023/early-2024, so this release is a backlog-clearing of npm audit findings rather than a functional release.

Architecture fit. Good, and deliberately shallow. The plugin auto-discovers a service provider, registers via the panel's plugin API, and resolves results against Filament resources you already expose. It does not own domain logic, so removing it later is a composer remove plus one line in the PanelProvider.

Integration feasibility. High. Runtime behavior for consumers is identical to v2.0.0. The practical effect of this release is on supply-chain posture: the patched packages carry known CVEs (prototype pollution in json5/loader-utils, SSRF in ip, and the @babel/traverse and browserify-sign advisories). Because these are devDependencies compiled into the shipped asset bundle, an application that consumes the prebuilt dist assets is not exposed to the vulnerable code paths — but SCA scanners that traverse vendor/ or the package's node_modules will still flag them.

Technical risk.

• Low, immediate: no code change, so upgrade risk is effectively a lockfile change.
• Medium, structural: the only commit activity is Dependabot. That is a low-feature-velocity signal, not neglect, but it means upstream will not chase Filament major-version compatibility for us.
• Medium, lifecycle: Filament 2 is a prior major. A plugin pinned to ^2.0 has a finite horizon; the real decision is not v2.0.0 vs v2.0.1 but whether we continue on Filament 2 at all.
• Unverified: no test/CI signal in this release. We should confirm the dist assets in the tag are rebuilt from the bumped toolchain rather than carried over stale.

Key questions.

1. Which Filament major are we running? If Filament 3/4, this package is out of scope entirely and the assessment stops here.
2. Do we build this package's assets in our own CI, or consume the committed dist bundle?
3. Does the palette respect Filament policies / canViewAny() per resource, or does it surface records a user cannot otherwise reach?
4. What is our SCA policy for devDependency CVEs in vendored packages — allowlist, ignore, or block?
5. Who owns the Filament major-upgrade path, and does the palette survive it?

Integration Approach

Stack fit. Laravel (9/10 era) + Filament 2.x + Livewire 2 + Alpine/Tailwind, PHP 8.x. Confirm via composer why-not jeremykenedy/filament-spotlight-2 ^2.0 before committing. If the estate has already moved to Filament 3/4, do not attempt to bridge — evaluate the maintained successor package instead.

Migration path.

• Greenfield (not installed → v2.0.1): composer require jeremykenedy/filament-spotlight-2:^2.0, register the plugin in the target PanelProvider, publish config and assets, then verify searchable-resource discovery in a non-production panel.
• v2.0.0 → v2.0.1: no application-side changes. Bump the constraint, composer update, rebuild caches, smoke-test the palette. Treat as a patch in the normal dependency cadence; it does not need its own change window.

Compatibility. Two surfaces to check: the Composer constraint against our Filament minor, and the shipped asset bundle against our published-asset version. Filament caches published assets aggressively — run php artisan filament:assets (or the v2 equivalent) and php artisan optimize:clear after upgrading, or you will silently serve the old bundle and conclude the release "did nothing."

Sequencing.

1. Confirm Filament major version and decide go/no-go on the package at all.
2. Spike in a dev branch; verify plugin registration and that the palette loads.
3. Review authorization scoping — enumerate exactly which resources are searchable and confirm per-user filtering.
4. Publish assets/config; pin the version in composer.lock.
5. QA keyboard navigation, empty/loading states, and result relevance on a realistically sized dataset.
6. Register the devDependency CVEs in the SCA allowlist with a rationale, or confirm they are out of scan scope.
7. Record the Filament upgrade decision as a tracked tech-debt item with an owner.

Operational Impact

Maintenance. Low touch. This release is dependency housekeeping with zero application-facing surface change; it should be absorbed in a routine sprint, not a planned upgrade. The ongoing cost is not patching the plugin but periodically re-validating it against Filament releases.

Support. Single-maintainer open-source with no SLA and no vendor escalation path. Mitigating factor: the blast radius is a search modal. If upstream goes quiet, we can pin, fork, or delete the plugin with an afternoon's work — it holds no data and no business logic.

Scaling. The palette issues a server round-trip per keystroke unless debounced. On large resource sets that is a real query-cost line item: ensure debounce + result caps are configured, and watch for N+1s when global search fans out across many resources. It is an admin-panel feature, so absolute volume is bounded by staff concurrency — not a capacity-planning concern, but a panel-latency one.

Failure modes.

• Silent break on Filament major upgrade — plugin fails to register or the panel boot errors; caught only by manual QA, not unit tests.
• Stale published assets after a Composer update, producing a "nothing changed" or "half-applied" state.
• Authorization leakage — a searchable resource returns records the viewer has no policy access to. This is the highest-severity failure mode and the one worth explicit testing.
• Search timeouts on large tables during broad queries.
• SCA noise — security scans flag devDependency CVEs and generate recurring triage work regardless of actual exposure.

Ramp-up. Hours for a competent Laravel/Filament developer to install, register, and configure. The learning cost is concentrated in permissions/config review and asset publishing, not in the package's code. Document the install steps and the asset-rebuild command in the team runbook so the next person doesn't rediscover the cache trap.