Nova Global Filter Laravel Package

Technical Evaluation

Architecture fit. Laravel Nova ships resource-scoped filters; filter state does not persist across resources or across a user's session in a way that supports "show me everything for tenant X" workflows. A cross-resource, persistent filter layer is a genuine gap in Nova's native model, so the problem statement is real and the conceptual fit with a Nova-based back-office is good. Nova is a paid, closed-source product with a narrow set of semi-public extension points (Nova::script, Nova::style, Nova::provideToScript, Vue components registered on Nova.booting, custom tools). Any package in this space lives on those points, and that is where the fit has to be judged — not on the feature description.

Integration feasibility. Mechanically feasible for a mid-level Laravel team in days. A Nova package of this shape typically consists of a service provider, a Filter subclass or middleware, and a compiled Vue component. The hard part is not installation; it is that a global filter almost certainly has to intercept queries broadly — via a global scope, a decorated NovaRequest, or injection into every resource's index query. That is a much higher-risk integration surface than a normal Nova card or field.

Technical risk — high. One star, zero dependents, single maintainer, no downstream validation. We would be the first integration test. Nova's extension contracts are stable in practice but not contractual, and a misapplied global scope can silently alter admin query results — a correctness risk in the back-office, not a cosmetic one. The listed last release date (2026-08-05) is anomalous relative to the present and should be treated as unverified metadata until confirmed against the repository tags directly.

Key questions.

• Which Nova majors are supported and actually tested (4.x, 5.x)? Is there a CI matrix, or only a composer.json constraint?
• Is filter state persisted in session, cache, a DB column, or localStorage? Is the key scoped per user, per team, per tenant?
• Does application happen via global scope, NovaRequest decoration, or per-resource filter injection? Does it affect metrics, lenses, exports, and relationship index endpoints — or only resource index lists?
• Does it compose correctly with existing global scopes (soft deletes, multi-tenancy) and with explicit withoutGlobalScopes() calls?
• Is compiled JS shipped, and against which Nova component API?
• Real maintenance signal: commit cadence over the last six months, open/closed issue ratio, response latency, bus factor.
• Are there tests at all? Absence of a test suite at this adoption level is disqualifying for production use without a fork.

Integration Approach

Stack fit. Laravel + Nova on PHP 8.x, Composer-installed, likely zero runtime dependencies — which is good. The gating check is Nova major alignment. If we run Nova 4 and the package targets Nova 5 (or the inverse), fit collapses before any code review is warranted. Verify this first, in five minutes, before spending engineering time.

Migration path. Additive and low-risk if adopted for new or lightly-customized panels. If existing resources already carry bespoke filters, expect a consolidation exercise and a user-behavior change: admins currently expect filters to reset per resource, and a persistent global filter violates that expectation. Plan a parallel-run period — enable behind a config flag for one internal team — rather than a cutover.

Compatibility. Needs explicit verification against Nova major, Laravel major, PHP minor, any tenancy package in use (e.g. stancl/tenancy), and any existing query-wide scopes. With zero dependents there is no compatibility corpus to borrow from; we generate that knowledge ourselves. Budget for vendoring or forking as the default posture rather than the exception.

Sequencing.

1. Source review gate: read the code, count LOC, confirm a test suite exists. No tests → stop or fork.
2. Disposable spike app: install, apply to two resources, then verify list, detail, relationship index, metrics, and exports all still return correct counts.
3. Fork-and-pin to a private VCS so upstream disappearance is a non-event.
4. Single-team, single-tenant pilot with a kill switch.
5. Broad rollout with internal documentation written at adoption time.

Operational Impact

Maintenance. Realistically self-maintained. At one star and zero dependents, the operating model is "adopt the code, not the package." We own Nova-major upgrade work — roughly 1–3 engineer-days per major, plus reactive fixes for Nova API drift. This should be staffed explicitly, not assumed to be free.

Support. No community to lean on, no issue corpus to mine, no Stack Overflow history. Every answer is internal tribal knowledge unless documented at adoption. Factor documentation into the initial estimate.

Scaling. Entirely implementation-dependent. A where on an indexed tenant column via global scope is negligible. A correlated subquery or join applied to every index and metric query is not — Nova metrics and dashboards are the first thing to degrade, and they degrade on the largest tables. Benchmark against production-scale data before pilot, not after.

Failure modes.

• Silent over-filtering — filter state leaks into metrics, exports, or relationship queries, under-counting admin data with no error surfaced. Highest likelihood, medium severity.
• Persistence leakage — session- or cache-keyed state shared across users or tenants, exposing another tenant's rows. Lower likelihood, unacceptable severity; this is the gate for production.
• Nova upgrade breakage — component API drift produces a blank or broken UI. Visible and recoverable, so low severity.
• Upstream abandonment — repository archived or maintainer disappears. Neutralized by the pinned fork.
• Stale state — a filter resurrecting after session rotation or logout. Confusing, low severity.

Ramp-up. A Laravel developer already fluent in Nova reads this source in half a day. A developer new to Nova's extension points needs 2–3 days, mostly learning how Nova injects scripts and how NovaRequest flows through IndexController. End-user training is one sentence — "this filter applies everywhere" — but that sentence matters, because the default mental model is wrong.

Recommendation. Interesting gap-filler, not a safe dependency at this adoption level. The overall score (15.3/100) and opportunity score (35.1) are consistent with that read. Fork-and-pin if source review shows tests and an active maintainer; otherwise build in-house, which is roughly one engineer-week and buys full ownership of the highest-risk query path in the admin panel.