Nova Big Filter Laravel Package

Technical Evaluation

Architecture fit. Nova Big Filter is a presentation-layer affordance, not a platform capability. It does not implement filtering — it reuses the existing Nova filter classes registered via ->filters([...]) on a resource and relocates them from the stock collapsed dropdown into an always-open, modal-based panel. The footprint is small: roughly 300 lines of Vue plus one PHP filter class and a service provider. That is a favorable architecture story in the abstract — minimal surface, no persistence layer, no data model changes, no server-side behavior. The real question is whether the architecture fits: an always-open panel is a vertical-space trade that only pays off on genuinely faceted resources (5+ filters, applied on nearly every operator session). If no resource in your Nova instance carries more than ~5 filters, this is chrome, not capability.

Integration feasibility. Mechanically simple on the right stack: composer require, auto-discovery of NrmlCo\NovaBigFilter\NovaBigFilterServiceProvider, publish assets, clear caches. Feasible without qualification only on Nova 1.x/2.x. On Nova 3+ — through 4's frontend rewrite and 5.x — the default assumption must be that it does not work unmodified, because the last release is 2019-10-16 and predates Nova 3, PHP 8, and every current Laravel LTS. Treat any install as a timeboxed spike (half a day), not a rollout. A first-party reimplementation of the same pattern is 1–2 days of frontend work including review.

Technical risk. This is an abandonment risk profile, not a code-quality risk profile. 36 stars, zero dependents, no release in six-plus years means no community triage, no upstream fixes, and no one to file a bug with; adopting it makes your team the maintainer. Layered on top:

• Version drift against a closed-source, fast-moving frontend — Composer constraints, Vue major, and the component registration API all need verification, not assumption.
• Component override collisions. If the package patches Nova's FilterMenu globally, any other Nova tool patching the same surface yields order-dependent, nondeterministic behavior — working in staging and failing in production, or breaking only after an unrelated package update.
• Filter state desync between panel and query string, which surfaces to operators as filters applied in the UI but absent from results, or stale filters surviving a reset.
• Stale build chain. Reviving a 2019 Node toolchain is a project, not a step; confirm dist/ assets are committed and load-bearing before committing to anything.
• Unverified gaps in accessibility, keyboard navigation, dark mode, and localization — the first things to generate complaints and, in admin tooling, the first to escalate into a compliance question.

Key questions for the team.

1. What Nova major are we on (composer show laravel/nova), and is there a near-term upgrade path?
2. Which specific resources carry more than five filters, and do operators filter on nearly every session — validated by analytics or session recordings, not internal taste?
3. Does any other Nova tool already override FilterMenu?
4. Do we need saved filter sets, cross-session persistence, faceted counts, or URL-synced state? The package does none of that, and extending abandoned code to get there is the worst available trade.
5. Does dependency policy require active maintenance or a release within 24 months? This fails on all counts.
6. Is the surface internal and low-stakes, with no compliance regime mandating maintained dependencies?
7. Who is the named owner of the fork?

Integration Approach

Stack fit. Nova 1.x/2.x only, on Laravel 5.5+ where provider auto-discovery removes the config/app.php edit. The Vue component targets a pre-Nova-3 frontend. Confirm three things before writing any code: the package's Composer constraints diffed against installed Nova/Laravel/PHP, the Vue major, and the Nova component registration API it targets. If the answer is Nova 3+, the recommendation is to treat the repository as a design reference and rebuild — do not install and hope the constraint solver saves you.

Compatibility and the migration path. There is no forward migration path from this package; the migration is off it. Two realistic routes: (a) vendor a pinned fork into app/Nova or a first-party package, or (b) rebuild the always-open panel as a small custom Nova filter component you own. Route (b) is the default recommendation on a modern stack — no abandonment risk, no stale build chain, and it usually satisfies supply-chain review outright. Route (a) is defensible only where the spike proves the UX and the Nova version is already frozen. Either way, convert the third-party dependency into owned code in the same commit that introduces it.

Sequencing.

1. Confirm the stack. Single most important step, and the one most likely to be skipped.
2. Build the filter inventory — count filters per resource and note types. If nothing exceeds ~5, close the ticket.
3. Grep Nova tooling for existing FilterMenu overrides before installing, and again before any Nova upgrade.
4. Run the spike on a throwaway branch or disposable Nova instance against real resources; capture screenshots and console errors; half-day budget.
5. Decide build-vs-port based on whether the always-open pattern measurably helps.
6. If adopting: vendor, pin, name an owner, document provenance.
7. Scope to two or three resources only, leaving low-density indexes on the stock dropdown so the blast radius of a future Nova major is bounded. Note that if the integration point is a global component override rather than per-resource registration, scoping must happen through your own wrapper or fork — plan for that up front.
8. Side-by-side filter-type checklist as the test oracle: text, select, boolean, date, date-range, multi-select, dependent — each renders, applies, and resets identically to the old dropdown.
9. Keyboard-only and dark-mode pass before rollout.
10. Add the regression line item to the Nova-upgrade checklist either way.

Asset and publish mechanics. The publish tag has drifted historically — check the README for the version actually installed, and fall back to php artisan nova:publish if the tag isn't registered. Clear view and config caches and hard-refresh, because stale compiled Nova assets are the number-one cause of "it installed but nothing changed."

Operational Impact

Maintenance. Zero dependents means zero community maintenance. Adoption transfers the full maintenance obligation to your team, permanently, for a UI affordance. Vendoring or rebuilding is what makes this survivable — it turns an unmaintained dependency into owned code with a named owner and a documented provenance, which is also what gets it past dependency-policy review. Budget the ownership, not a vendor relationship that doesn't exist.

Support. There is no upstream to escalate to. Failures route to whoever owns the fork, and the debugging path is browser-side, not server-side: network tab for a 404 on the compiled JS, console for component-not-registered errors, and confirmation that published assets landed where Nova expects. Server logs will tell you nothing useful here. Keep the deployment surface internal and low-stakes; this has no business near customer-facing views.

Scaling. The meaningful scaling axis is not load — it's scope creep and layout pressure. The panel consumes vertical space permanently and degrades on narrow viewports and small result tables, so it should be applied per-resource, not globally. Functionally, the package is a dead end: no saved filter sets, no cross-session persistence, no faceted counts, no URL-synced state, no guarantees around date-range, boolean, multi-select, or dependent filter rendering. Any of those requirements converts this from a spike into a rebuild — and rebuilding is the cheaper outcome.

Failure modes to plan for.

• Blank or partially rendered admin screen from failed component registration or a missing compiled asset — the most common install failure, and the most alarming to operators.
• Override collision with another Nova tool patching FilterMenu — order-dependent, nondeterministic, and capable of diverging between staging and production.
• Filter state desync — UI shows a filter that results don't reflect, or a filter survives a reset. Test explicitly: apply, reload, reset, apply a different one, navigate back.
• Silent breakage on the next Nova major, which is why the regression checklist line item is the cheapest insurance available.
• Accessibility degradation escalating into a compliance question in admin tooling.

Ramp-up. Low for end users — existing filters behave identically, only the affordance moves, so there is no training burden beyond "the menu is now always open." Moderate for the owning engineer: read the service provider (to determine whether it registers its own component or overrides Nova's FilterMenu — that distinction sets the entire risk profile), read the Vue component end to end, and confirm the committed assets are load-bearing. Roughly half a day to spike and evaluate, one to two days to rebuild as an owned component including review. This belongs in an admin-polish backlog item scoped in days, with no roadmap line item and no ongoing strategic ownership — approve the UX without approving the dependency, and capture the design idea rather than installing the artifact.