Nova Big Filter Laravel Package

Product Decisions This Supports

• Whether filter-heavy admin screens deserve UX investment at all. This package forces an explicit decision: should Nova resource index filters be permanently visible instead of collapsed behind a dropdown? For internal ops surfaces where operators filter on nearly every session — support triage, order/catalog management, moderation, lead pipelines — always-visible facets are a plausible, measurable efficiency win. For occasional filtering, the panel is pure chrome and a vertical-space cost. Validate against operator behavior (session recordings, filter-event analytics, interviews), not internal taste.

• Build vs. buy vs. reference. At 36 stars, zero dependents, and a last release of October 2019, this is not a "buy" in any commercial sense. It is a small Vue component plus a PHP filter class under MIT (roughly 300 lines of Vue plus the filter class). The realistic options are: (a) rebuild the always-open panel as a first-party Nova filter component, (b) vendor a pinned fork into app/Nova or an internal package, or (c) skip it. Treat the repo as a design reference and a head start, not a runtime dependency.

• Roadmap framing and scope discipline. This is cosmetic polish layered on a paid first-party package (Laravel Nova). It carries no strategic weight and should never sit on the roadmap as a line item with ongoing ownership. It belongs in an "admin polish" backlog entry scoped in days, not a quarter's allocation.

• Use-case fit as a product filter. Good fit: internal ops dashboards with many facets and modest result sets, where an open panel can coexist with the table. Poor fit: customer-facing surfaces, space-constrained layouts, narrow viewports, or any case where filter state must be saved, shared, or URL-synced — this package does none of that. Its stated value proposition ("the menu is always open") is a vertical-space trade that only pays off where filter density is high.

• Supply-chain posture as a decision input. An unmaintained 2019 package touching your admin surface is a small but legitimate audit question. Forking or rebuilding converts an unknown third-party dependency into owned code and usually resolves the concern outright. That framing lets a PM approve the UX idea without approving the dependency.

• Reading the opportunity signal honestly. The relatively high opportunity score reflects a sound underlying UX concept, not the package's fitness for a modern stack. Capture the idea; do not install the artifact. Do not let a score substitute for a compatibility check.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Laravel Nova 1.x or 2.x with no near-term upgrade path. The last release (2019-10-16) predates Nova 3, Nova 4's frontend rewrite, PHP 8, and every current Laravel LTS. Run composer show laravel/nova and note the major version first. Default assumption: it will not work unmodified on anything modern until verified in a sandbox.
• The admin panel is internal and low-stakes. No customer data exposure beyond what operators already see, and no compliance regime mandating actively maintained dependencies with security response.
• You have a named owner for the fork. Zero dependents means zero community triage, zero upstream fixes, zero bug reports. You become the maintainer the moment you adopt it — say so in the same commit that introduces the code.
• The always-open pattern is validated by operator behavior, not by internal preference.
• Filter density justifies it. If no resource carries more than roughly five filters, close the ticket; the stock Nova dropdown is fine. Scope the panel to the two or three resources that justify it rather than globally, so the blast radius of a future Nova upgrade is bounded.
• No other Nova tool overrides the same FilterMenu component. Global overrides plus another override produce order-dependent, nondeterministic behavior — it can pass in staging and break in production, or break only after an unrelated package update. Grep your Nova tooling before install and again before any upgrade.

Look elsewhere — or simply build it — when:

• You are on Nova 3+. A reimplementation as a small custom Nova filter component is self-owned, free of third-party risk, and typically one to two days of frontend work including review. That is usually the better trade even at higher initial cost.
• Dependency policy requires active maintenance, security response, or a release within 24 months. This fails all three.
• You need more than cosmetic layout: saved filter sets, cross-session persistence, faceted counts, URL-synced filter state, or hard guarantees around date-range, boolean, multi-select, and dependent filter rendering. Extending abandoned code to reach those is the worst of both worlds.
• You need accessibility, keyboard navigation, dark-mode, or localization guarantees. These are unverified gaps, and in admin tooling they can escalate into compliance questions.

The practical on-ramp in any case is a timeboxed spike — half a day on a throwaway branch or disposable Nova instance, wired into one resource where the pain is real, with screenshots and console errors captured against your real filter types. Then make the build-vs-port call with evidence. Either way, bake it into your Nova-upgrade regression checklist: "verify filter panel renders, applies, and resets across all filter types in every resource using it."

How to Pitch It (Stakeholders)

One-liner: A small, MIT-licensed UI add-on that keeps Laravel Nova's filter menu permanently open so operators working faceted queues can combine several filters at once — but it is a 2019 artifact, so we should treat it as a design reference and rebuild the pattern ourselves rather than adopt the dependency.

For executives: This is admin-panel polish, not a platform capability. It addresses a real but contained inefficiency: operators who filter repeatedly on triage, order, or moderation screens currently dig through a collapsed dropdown every time. The upside is faster daily work in internal tooling; the downside of adopting as-is is an unmaintained 2019 package on an admin surface, with no vendor, no security response, and no one to call when Nova upgrades. Recommendation: approve a half-day evaluation spike, then fund a small first-party rebuild (one to two days) if operators confirm the pain. No recurring cost, no vendor relationship, no roadmap line item.

For engineering: The idea is worth keeping; the code is not a dependency to track. It is a lightweight Vue component plus a PHP filter class that changes the affordance around Nova's existing filters — filter logic is untouched, which is also our test oracle. Compatibility with Nova 3+ is unverified and unlikely; the frontend rewrite makes the default assumption "will not work unmodified." If we adopt, we vendor a pinned fork with a named owner and documented provenance, because at zero dependents we are the maintainer. The preferred path on a modern stack is a small custom Nova filter component we own — same UX, no stale Node build chain, no supply-chain review friction, no order-dependent conflicts with other tools patching FilterMenu. Known gaps to QA before rollout: accessibility and keyboard navigation, dark mode, localization, and filter-state desync between the panel and the query string.

What we are explicitly not buying: saved filter sets, cross-session persistence, faceted counts, URL-synced state, dependent-filter support, or any customization beyond the button label and behavior. If the product needs those, it is a build, not a patch — and patching abandoned code to get there is the highest-cost, lowest-reward path available.