Nova Mega Filter Laravel Package

Technical Evaluation

What this is, in product terms. A configuration-layer add-on for Laravel Nova resource index screens. It replaces stock Nova filter classes with a combinable condition panel so internal users (support, ops, finance) can slice large datasets without filing engineering requests. It is admin-surface tooling only — it does not touch the customer-facing product, pricing, or anything carrying an external SLA. That containment is the most important fact about the package: the cost of being wrong is a revert, not an incident.

Architecture fit. Fits cleanly if we are a Laravel + Nova shop. It plugs into Nova's existing filter extension point — no new service, no queue, no storage beyond whatever saved presets use. It does not introduce a new runtime, a sidecar, or a data path. For an internal tooling stack, that is close to the ideal shape of a dependency: bolt-on, resource-scoped, reversible per resource.

The fit weakens in three places:

• It reaches into Nova internals. The blast radius of a broken integration is the entire admin UI — a service-provider or class-not-found fatal, not a degraded filter panel. That converts a cosmetic dependency into an availability dependency for every internal workflow routed through Nova.
• It is unproven at our data volumes. Relationship filters (whereHas) are both the selling point and the primary performance hazard. On high-cardinality or unindexed tables, an index page becomes a sequential scan.
• It can widen visibility if misconfigured. Filters shape result sets. If a resource policy doesn't constrain rows under an applied filter, that is a security finding, not a UX finding, and it must be tested with a restricted user — never an admin.

Integration feasibility. Feasible in hours-to-days, not weeks. The engineering learning curve is the Nova filter API itself, not this package; a Laravel-fluent engineer ramps in roughly half a day. The real cost is not installation — it's the per-resource governance: whitelisting columns, verifying indexes, testing authorization, and maintaining a preset inventory.

The blocking unknowns. Two items must be resolved before any roadmap commitment, and both are cheap to check:

1. What the product actually does. The marketing copy describes nested AND/OR groups with saved presets; the developer notes describe a searchable multi-select replacement for the stock select filter. Those are different products with different value propositions. We cannot size a story, or claim the "reduce ad-hoc data-pull requests" benefit, until we know which one we're getting.
2. Whether v1.1.0 still supports Nova 4. The changelog reads "Nova 5 Support" but does not say what was dropped. If the constraint tightened to ^5.0 only, adopting this release is a silent platform bump that raises our PHP/Laravel floor even if we never use a Nova 5 feature. That is the single most expensive mistake available here, and it is caught by reading one file.

Secondary unknowns: the package identity is ambiguous (repo at dcasia/nova-mega-filter, listed as digital-creative/nova-mega-filter) — confirm the Packagist name before anyone types composer require. The recorded last-release date (2026-09-19) is anomalous and should be reconciled against the actual tag list before it anchors any planning date.

Technical risk summary. Low-to-moderate, well-bounded, with three named risks: (a) upstream abandonment — 85 stars, zero dependents, effectively single-maintainer, one first-time contributor behind the only substantive release; (b) Nova-major upgrade fragility — no matching release means a broken admin UI; (c) silent correctness failure — a filter that stops applying while the UI still renders and results still look plausible. Risk (c) is the dangerous one because it produces trusted wrong data, e.g. an export of "unpaid invoices" that includes paid ones. None of these are reasons to reject; all of them are reasons to adopt deliberately with a rollback pin.

Key questions for the team.

• Does the source deliver nested AND/OR groups with presets, or a multi-select filter replacement? Which do we actually need?
• What is the exact require constraint at v1.1.0, and does it preserve Nova 4 support?
• Are our largest filterable tables indexed on the columns and foreign keys we'd expose?
• Do our resource policies constrain rows under an applied filter, verified as a restricted user?
• Do we have a documented fork/patch policy before we need one?
• Who is the named internal owner for upgrade tracking?

Integration Approach

Stack fit and gating decision. This is a pure Nova-layer dependency. Two gates determine whether it enters the roadmap at all:

• Gate 1 — Are we on Nova? If not, stop.
• Gate 2 — Are we on Nova 4 with no near-term Nova 5 plan? Then v1.1.0 is functionally a no-op and should not drive any decision. If Nova 5 is planned or underway, v1.1.0 is the required floor (v1.0.5 will not run there) and this becomes an upgrade gate — a named line item in the Nova 5 workstream so it isn't discovered late, not a feature in its own right.

Build vs. configure. The honest comparison is adopt a community package against hand-write and own custom Nova filter classes. Configured adoption costs hours; hand-rolling equivalent nested-filter UI across multiple resources costs days per resource and then lives on our maintenance ledger permanently. Adopting moves a capability off our roadmap and onto a third party's release cadence. That is the correct trade for admin-surface functionality with no SLA and no differentiation value — and the wrong trade anywhere filtering logic becomes a product differentiator. It isn't one here.

Migration path — additive, not a rip-out. Do not remove existing Nova filter classes on day one. Register the new panel alongside native filters on a pilot resource, have a power user run the same query through both, and diff the result sets. That diff is a free correctness test. Consolidate only once results match.

Pilot selection. One low-traffic, non-sensitive resource — internal Tickets or Users. Not Orders, nothing finance reconciles against. Register the filter, load the index, and immediately compare the filtered result set against the equivalent manual query (->where(...)->whereHas(...)->count(), plus a toSql() dump). We are validating that the filter applies before validating that it's pleasant. Do this in staging at realistic data volume: a panel that looks correct on 500 seeded rows and silently no-ops on 500k production rows is precisely the failure mode we're buying insurance against.

Compatibility sequencing.

1. Confirm Packagist name and tag list; read composer.json at the tag (answers Gate 2).
2. Pin the exact version — digital-creative/nova-mega-filter:1.1.0 — not a caret range, with a rollback pin to v1.0.5 held open until dual-support is verified.
3. Publish assets if the package provides them, and inspect what lands in config/ and resources/ before committing.
4. Staging pilot on one resource → golden-query verification → production on that same resource → next resource. Staggered, per-resource, never a fleet-wide flip.

Sequencing against the Nova upgrade. If Nova 5 is on the roadmap, install and validate this package before the Nova major lands, on the current version, so the Nova upgrade has one fewer unknown. If a Nova major ships without a matching package release, reserve one to two days of fork capacity and add the package to the Nova-major-upgrade checklist.

Scope discipline at integration time. Whitelist, don't auto-expose. Start with three to five columns per resource — the ones that actually appear in support tickets — and add only in response to a real request. Cap relationship depth at one level, deliberately. A three-level nested whereHas on a large pivot table is the single most expensive thing an internal user can do to the admin panel, and they will do it accidentally.

Operational Impact

Maintenance. Ongoing cost is low but non-zero, and it is tracking cost rather than engineering cost. The package needs a line in the Nova-major upgrade checklist, a small fork/patch reserve each cycle, and — critically — a documented escalation path written down and executable before pressure: upstream issue → in-house patch/fork → hand-rolled Nova filter classes. Under MIT, forking is available; confirm the org's fork policy now, while nothing is on fire. This should never appear on a critical-path runbook without that path documented.

Ownership. Name one engineer as the ongoing owner for upgrade tracking. Ownership concentration in the upstream project is the defining risk here — 85 stars, zero dependents, effectively single-maintainer, with the only substantive recent release contributed by a first-time contributor. That needs a matching owner on our side, or the dependency quietly rots.

Support. Community only. No SLA, no security-response commitment, no contractual recourse. Acceptable strictly because the blast radius is the admin surface and the remedy is a revert. It must stay out of any conversation involving an external SLA or customer-facing commitments.

Configuration as an operational asset — the preset problem. Saved presets are the feature that makes this package worth adopting: reusable slices owned by ops users instead of one-off engineering requests. But presets are persisted state and they rot. A preset referencing a removed or renamed column becomes a confusing empty result, not an error. Operationally this requires: a documented preset inventory per resource in the repo (or a seed file for standardised defaults), re-verification whenever a resource's columns change, and an up-front decision on whether presets are per-user or shared — because that determines whether one bad preset is one user's problem or the whole team's.

Scaling. Two distinct scaling axes:

• Horizontal — number of resources with the panel enabled. Cost scales linearly in configuration and governance effort, not infrastructure. Stagger the rollout and document each resource's filter definitions in the internal repo as you go; the panel's behaviour is defined entirely by configuration that is not visible from the resource class alone, so the person debugging this in six months will not be the person who configured it.
• Data volume — the real constraint. Pair every filter definition with an index before exposure. Confirm foreign keys are indexed. Run EXPLAIN on the largest filtered table with the filter active, not on the bare query, and treat an unexplained sequential scan as a blocker for that column rather than a nice-to-have. If a relationship filter is genuinely needed on a high-cardinality table, whether the resource owner should be allowed to configure it at all is a policy decision, not a code decision.

Failure modes. Three, in descending order of severity:

1. Silent no-op — worst. After config drift or an upgrade, the filter stops applying while the UI renders normally and results look plausible. Users then trust unfiltered output and export or act on it. Guard with a golden-query regression check in staging after every upgrade: a known filter must return the same row count it did before. Also verify what the panel emits for pathological groups — zero conditions, a single condition, AND inside OR inside AND — since these are where query builders produce vacuously-true clauses and results are subtly wrong rather than obviously broken.
2. Admin UI outage. Nova-internals coupling means a Nova major without a matching package release produces a fatal across the whole admin surface. Mitigate with a pinned version, staged Nova upgrades, and the fork reserve.
3. Visibility widening. Filters shape result sets; a misconfigured policy check lets a scoped user broaden what they see. Re-run the restricted-user authorization test on any policy change and after every Nova upgrade. This is a security bug class, and it is the one failure mode that would force an immediate revert regardless of the package's other merits.

Debugging posture. Isolate, don't inspect the UI. Start from generated SQL (toSql() / getBindings()), then remove filters one at a time from the resource's filters() array to find the responsible definition. Nova's own request/query logging or Telescope is more reliable here than the panel's serialized state.

Ramp-up. Roughly half a day for a Laravel-fluent engineer, and the learning curve is the Nova filter API rather than this package. The expensive ramp-up is organisational, not individual: establishing index-verification habits, the preset inventory, the authorization test, and the upgrade checklist.

Adoption signal to hold ourselves to. Before adopting, count the recurring requests for filter combinations native Nova filters can't express — data pulls, ad-hoc exports, "can we slice orders by X and Y." That count is the justification and, more importantly, the metric to re-check afterward. If it doesn't fall, we've relocated the requests rather than reduced them, and the dependency isn't earning its tracking overhead.

Verdict for planning. Treat as a conditional, low-priority adoption — contingent on resolving the two blocking unknowns (actual capability, Nova 4/5 constraint) and on Nova 5 being on the roadmap. Do not adopt for parity with filters we already have, not on Nova 4 with no Nova 5 plan, and not where the largest filterable tables are high-cardinality and unindexed. If it clears those gates, scope it as a small upgrade-gate line item with a named owner, a pinned version, and a written rollback — not as a standalone feature on the roadmap.