Nova Detached Filters Laravel Package

Technical Evaluation

Architecture fit This package occupies the thinnest possible layer of a Laravel Nova application: it takes filters that Nova already renders inside its filter dropdown and re-renders chosen ones as standalone panels on the resource index toolbar. There is no migration, no schema change, no new route, no persistence, and no alteration to filter query logic — the filters continue to execute exactly as before. For a TPM that classification matters more than the feature itself: this is an internal admin-ergonomics change, fundable and scopeable independently of the customer-facing roadmap, with a blast radius confined to staff operators. A failure degrades an internal convenience, not a customer transaction.

The trade-off to internalize is that this is a presentation adapter bolted onto Nova's proprietary filter internals. Nova is closed-source and commercially versioned on its own cadence; anything hooking its filter menu or index toolbar inherits coupling to code the team cannot read at review time and does not control. That is acceptable for a convenience layer with a documented exit, and unacceptable as something the business becomes structurally dependent on.

Integration feasibility High, conditional on the team already standardizing on Laravel Nova 4.x/5.x (Vue 3). Adoption is a composer require with an auto-discovered service provider plus a small per-resource change — a trait, base-class override, or filter flag. No consumer build step, no asset pipeline work, no data migration. A competent backend developer completes a spike inside a day, which means the decision cost dominates the implementation cost. The real feasibility risk is dependency governance, not technical difficulty: a single-maintainer MIT package at ~63 stars with zero listed dependents should be treated as a pinned experiment with a fork plan, not an adopted platform dependency.

Technical risk

• Nova version coupling — highest. The package modifies Nova's internal filter and toolbar components. Release 3.0.1 (Feb 2025) exists specifically to fix types for Nova 5 — direct evidence that every Nova major requires a package-side patch. Each Nova upgrade becomes a re-verification task the package cannot self-heal.
• Filter-state semantics. Detached filters must still participate in Nova's URL-serialized filter state alongside pagination, sorting, and reset. Any desync produces shared or bookmarked index URLs whose visible controls contradict the rendered data — a reliable generator of "the numbers look wrong" tickets.
• Override collisions. Anything else touching the index toolbar or filter menu (page managers, theme packs, other filter plugins) can yield duplicated or missing controls that only surface at runtime.
• Thin-wrapper risk cuts both ways. Small surface means small upside and small downside. That is precisely why an internal fork is a realistic branch of the decision tree rather than a last resort, and why diligence should stay proportionate to the value at stake.
• Abandonment exposure. No data path, so no direct security exposure — but eventual hard incompatibility with a future Nova major if upstream goes quiet.

Key questions to resolve

1. Which Nova major are we on, and is the package version pinned together with an explicit Nova constraint in composer.json?
2. Which specific filters (status, owner, tenant, date range) on which specific resources are used constantly — and is that friction measured or assumed?
3. Does detached filter state survive pagination, sort changes, URL bookmark/share, and reset? Has anyone tested it, or is it an assumption?
4. What else currently modifies our Nova index toolbar that could collide?
5. Who is the named owner, what is the quarterly budget in hours, and what is the documented rollback?
6. Are we organizationally prepared to fork and vendor ~100 lines if upstream stalls or breaks on a Nova bump?

Integration Approach

Stack fit Target: Laravel 10/11, PHP 8.1+, Nova 4.x/5.x. Outside Nova — Filament, plain Blade, an in-house React admin — the package is inert and should not be evaluated at all. Within Nova it is a low-cost lever improving a daily-use internal product without touching domain code, which is exactly the profile that fits an ops-tooling line item.

Migration path Adopt per-resource and incrementally, never globally on day one:

1. Pick one internal resource where operators already complain about filter friction.
2. Promote only the 1–2 highest-frequency filters (status, owner); leave the rest in the dropdown.
3. Measure before/after — filter usage counts, time-to-filtered-view on a repeated ops query, or a short structured pulse from the ops team.
4. Expand to 2–3 resources only on a clear, articulated win.
5. Codify a one-page convention: which filters are detached, why, what query-cost check was done, and who owns the dependency.

Rollback is a deleted trait/flag plus one Composer line — demonstrable inside a sprint. That reversibility is the core of the business case and should be stated explicitly in the approval request.

Compatibility Pin the package version and an explicit Nova constraint together so an incidental Nova bump cannot silently orphan it. Add a mandatory line to the Nova upgrade runbook: re-verify detached filters after any Nova version change. Pre-check overlap with every other index-toolbar-modifying dependency. Confirm asset-publish behavior (nova:publish / vendor:publish) is documented, since stale published assets are where this class of package typically breaks first and most confusingly.

Sequencing

1. Spike, ≤1 day: install in a scratch Nova instance; verify rendering, URL/filter state, pagination interaction, and coexistence with two existing filters.
2. Decision gate: adopt as a pinned dependency vs. fork internally vs. build a small in-house equivalent. All three are legitimate; forking is not a failure.
3. Pilot: one resource, high-frequency filters, real operators, measured.
4. Expand: 2–3 additional resources with demonstrable friction.
5. Codify: convention doc, named owner, upgrade-runbook entry, pinned constraints committed.

Operational Impact

Maintenance Low code cost, moderate dependency-maintenance cost. Realistically a few hours per quarter for one named backend developer to review upstream activity and re-validate after Nova releases. Set a standing trigger: if upstream is quiet across two Nova majors, fork and vendor internally — measurable in half a day at this code volume. The dangerous pattern is not the maintenance itself but the absence of a named owner when a Nova upgrade lands.

Support Community-only. GitHub issues, no SLA, no vendor relationship. At ~63 stars with zero listed dependents, assume we are near the front of the queue for any bug and that triage is our problem. The mitigation is shallow integration plus documented removal, not negotiation or warranty. State this plainly to stakeholders so nobody later mistakes it for a supported vendor component.

Scaling Runtime cost is negligible — detached filters execute identical queries to their dropdown equivalents. The real scaling risk is behavioral: always-visible controls invite always-on broad filters (unbounded date ranges, "all statuses") firing on every index load against large tables, and they consume horizontal toolbar space. Enforce two guardrails: a query-cost review for any promoted filter, and a cap of ~2–3 detached filters per resource to preserve layout on narrower viewports.

Failure modes to plan for

• Nova upgrade breaks the component → index page renders blank or throws console errors; that resource is unusable until patched or the dependency removed. Mitigation: rollback commit ready, dependency flagged as a known Nova-upgrade checklist item, staging validation before production Nova bumps.
• Filter-state desync → visible controls disagree with the data shown, eroding operator trust in the admin panel faster than the ergonomics win builds it. Mitigation: explicit spike tests for pagination, sort, bookmark, and reset before pilot sign-off.
• Toolbar collision → duplicated or vanished filters from a competing plugin, appearing only at runtime. Mitigation: inventory toolbar-modifying dependencies during the spike.
• Upstream abandonment → no fix arrives on a future Nova major. Mitigation: fork-and-vendor is pre-approved as a half-day task, not an emergency.

Ramp-up Essentially zero for backend developers — the integration is a trait or flag plus Composer. The ramp-up cost that matters is organizational: establishing the owner, the upgrade-runbook line, and the per-resource convention so the change does not quietly rot into an untracked dependency. Budget a short review cycle for that governance work; it is larger than the code change and is what keeps a 63-star single-maintainer package from becoming an unowned liability.