Nova Big Filter Laravel Package

Getting Started

Check the stack before you type composer require. The last release is 2019-10-16, which predates Nova 3, Nova 4's Vue rewrite, PHP 8, and every current Laravel LTS. This is the first thing you do, not the last:

composer show laravel/nova | grep versions
php -v

On Nova 1.x/2.x, continue. On Nova 3+, stop and treat the repo as a design reference — the always-open filter panel is roughly 300 lines of Vue plus one PHP filter class, and rebuilding it as a first-party component is a one-to-two-day job with no abandonment risk. Do not let the constraint solver decide your architecture.

Install (Nova 1/2 only).

composer require nrml-co/nova-big-filter

Auto-discovery registers NrmlCo\NovaBigFilter\NovaBigFilterServiceProvider, so no config/app.php edit is needed on Laravel 5.5+. Then publish assets — the tag name has drifted across versions, so try the common variants and fall back to the blunt instrument:

php artisan vendor:publish --tag=nova-big-filter-assets
# fallback if the tag isn't registered:
php artisan nova:publish
php artisan view:clear && php artisan config:clear

Hard-refresh the browser afterwards. Stale compiled Nova assets are the number-one cause of "it installed but nothing changed."

Where to look first. Read three things in vendor/nrml-co/nova-big-filter/ before wiring anything:

1. The service provider. Does it register its own component, or does it override Nova's FilterMenu? That single fact determines your entire risk profile and whether it will collide with other Nova tooling.
2. The Vue component under resources/js/. It's small — read it end to end rather than skimming. You need to know exactly how it reads and writes filter state, because that's where the bugs will live.
3. The compiled assets in dist/. Confirm they're committed and load-bearing. Reviving a 2019 Node toolchain to rebuild them is a project, not a step.

First use case. Pick one resource where the pain is measurable — a support triage queue, an order index, a moderation list — somewhere operators apply three or more filters per session. Wire it into that resource only, verify it against real data and every filter type you actually use, and leave everything else on the stock dropdown. The value proposition ("the menu is always open") is a vertical-space trade, and it only pays off where filter density is genuinely high.

Implementation Patterns

Start with the filter inventory, not the code. Before registering anything, count filters per resource and note their types. If no resource carries more than roughly five filters, close the ticket — the default Nova dropdown is fine and you're adding chrome. The always-open panel earns its screen real estate only against genuinely faceted resources, and it degrades on narrow viewports and small result tables.

Scope it to specific resources. The package is a presentation-layer affordance; treat it that way. Apply it to the two or three resources that justify it rather than globally, so the blast radius of a future Nova upgrade stays bounded and low-density indexes don't lose table space for nothing. If the integration point turns out to be a global component override rather than a per-resource registration, that scoping has to happen through your own wrapper or your own fork — plan for it up front.

Existing Nova filters keep working; that's the whole point. You're not rewriting filter logic, you're changing the affordance around it. Every filter class already declared in the resource should render and behave identically:

public function filters(Request $request)
{
    return [
        new Filters\Status,
        new Filters\AssignedTo,
        new Filters\CreatedBetween,
        new Filters\HasAttachments,
    ];
}

That makes your filter list a ready-made test oracle. Build a side-by-side checklist — text, select, boolean, date, date-range, multi-select, dependent — and confirm each one renders, applies, and resets in the panel exactly as it did in the dropdown.

Vendor it if you adopt it. Thirty-six stars, zero dependents, no community triage, no upstream fixes, nobody to file a bug with. The moment you adopt this, you are the maintainer. The realistic pattern: copy the Vue component and provider into a first-party package or app/Nova, pin it, and document provenance plus a named owner in the same commit that introduces the code. That converts an unmaintained third-party dependency into owned code and usually clears dependency-policy review outright.

Run installation as a timeboxed spike first. Half a day, on a throwaway branch or a disposable Nova instance: install, screenshot, capture console errors against your real resources, judge whether the always-open pattern actually helps. Then decide build-vs-port with evidence instead of opinions. If the UX is worth having, the default recommendation on a modern stack is still to rebuild it as a small custom Nova filter component you own.

Bake it into your Nova-upgrade regression checklist either way. Whether you vendor or rebuild, add one explicit line item: "verify filter panel renders, applies, and resets across all filter types in all resources using it." That's the cheapest insurance against silent breakage on the next Nova major.

Gotchas and Tips

The compatibility assumption is the risk, not the code. Six years without a release against a closed-source, fast-moving frontend means the default assumption must be that it will not work unmodified on anything modern. Verify in a sandbox before spending time on anything else. Diff its Composer constraints against your installed Nova/Laravel/PHP, confirm the Vue major, and confirm the component-registration API it targets. A promising opportunity score is not a compatibility check.

Component override conflicts are order-dependent and nondeterministic. If this package patches Nova's FilterMenu globally, any other Nova tool patching the same surface produces behavior that depends on registration order — meaning it can work in staging and break in production, or break only after an unrelated package update. Grep your Nova tooling for other FilterMenu overrides before installing, and again before any Nova upgrade.

Filter state desync is the most likely runtime bug. If the panel and Nova's query string drift apart, operators see a filter "applied" in the UI that isn't reflected in results — or worse, a stale filter that survives a reset. Test explicitly: apply a filter, reload, reset, apply a different one, navigate back. If you need saved filter sets, session persistence, faceted counts, or URL-synced state, this package does none of that, and extending abandoned code to get there is the worst of both worlds — build it yourself.

Debugging goes through the browser, not the server. When the panel doesn't appear, the failure is almost always asset-related: check the network tab for a 404 on the compiled JS, check the console for Vue "component not registered" errors, and confirm the published assets actually landed where Nova expects. php artisan nova:publish is the blunt instrument when the package's publish tag isn't registered or has drifted. A blank or partially rendered admin screen usually means component registration failed outright.

Know the gaps before your users find them. Expect nothing here for accessibility, keyboard navigation, dark mode, or localization. Those are the first things to QA and the first to generate complaints in admin tooling, where degraded screen-reader access can escalate into a compliance question. Do a keyboard-only pass and check the panel under Nova's dark mode before rollout.

The button label and behavior are your extension points — that's about it. Anything beyond cosmetic layout (dependent filters, date-range rendering guarantees, cross-resource filter memory) is out of scope and should be a rebuild, not a patch. Patching abandoned code to add capability is the highest-cost, lowest-reward path available.

Keep it off the roadmap as a line item. This is admin polish scoped in days, not a platform capability with ongoing ownership. Fund the spike if operators confirm the pain, keep the fork documented and owned if you adopt it, and don't budget for a vendor relationship that doesn't exist.