Nova Range Filter Laravel Package

Technical Evaluation

Architecture fit. The package occupies a well-defined extension point in Nova: a Laravel\Nova\Filters\Filter subclass with an accompanying Vue component that emits a {min, max} payload, applied server-side as a whereBetween (or equivalent) on the resource query. Nova filters are registered per-resource via filters(), so adoption is additive — no core modification, no service-provider coupling beyond asset registration. Architectural footprint is genuinely small: likely one filter class plus one compiled JS asset. That is the package's only real strength.

Integration feasibility. Low effort in the happy path: composer require, publish assets, add the filter to a resource's filters() array, pass a column name. Realistically 1–4 hours for a first filter, under a day for a resource group. The blocker is version scope: the description scopes to "Nova v3+", but Nova 4 moved to Vue 3 / Inertia and a different asset pipeline (nova.mix), and Nova 5 continues that lineage. A v3-era compiled component will not reliably mount in a Nova 4/5 filters panel. This is the decisive feasibility question.

Technical risk. High, concentrated in ownership rather than code quality:

The code is small enough that "risk" is really "you will own it." That is a fork-and-maintain decision, not a dependency decision.

Key questions.

• Does it support Nova 4/5, or is the apply() signature and asset the v3 generation only?
• Is the asset shipped pre-compiled, or does adoption require an npm build step in our app?
• Does it cast inputs (int vs decimal vs date, timezone handling) and how does it behave when one bound is empty or min > max?
• Does it use whereBetween on the raw column, and does it compose correctly with soft deletes and other active filters?
• License terms and test coverage — is there any?
• Given a 0.0025 score against a 6.81 opportunity score, is the capability valuable while this implementation is not?

Integration Approach

Stack fit. Clean only on Laravel 8/9 + Nova 3 with an existing filter-driven admin. On Nova 4/5 or PHP 8.2+, treat as incompatible until proven otherwise.

Migration path. Three viable routes, in ascending cost:

1. Adopt as-is — only if we are pinned to Nova 3 and the spike passes.
2. Vendor/fork — copy the filter class and component into app/Nova/Filters, keep the MIT attribution, drop the Composer dependency. Preserves the UI work, removes the abandonment risk, and gives us the patch surface. Preferred default.
3. Reimplement — a RangeFilter base class plus a small Vue component is ~1–2 engineer-days against Nova's documented filter API. Worth it if we need Nova 4/5 or custom type handling.

Compatibility. Verify against the pinned Nova version before commitment. Confirm the filter class signature matches our Nova major, and confirm assets publish and render in the filters dropdown. Run it on one resource, not the whole admin.

Sequencing.

1. Timeboxed spike (≤0.5 day): install in a scratch branch, render the filter on one resource, verify query output via toSql()/query log.
2. Decide adopt-vs-fork based on the Nova version answer, not on effort.
3. If forking: vendor the code, add a test asserting the generated whereBetween clause, tag it internally.
4. Roll out per-resource, starting with the highest-traffic index view to surface index problems early.
5. Only then consider abstracting into a shared base filter for reuse.

Operational Impact

Maintenance. Upstream maintenance is zero — archived, single star, no dependents. Every future Nova upgrade becomes our problem. Whether adopted or forked, budget for someone owning the Vue component and its Nova-major compatibility. A fork is cheap to hold but accrues a small, permanent tax.

Support. No vendor, no community, no issue backlog to lean on. Internal documentation of the fork and its query semantics is mandatory, not optional.

Scaling. The filter itself is O(1) overhead — a single predicate appended to an already-bounded index query. The real scaling risk is database-side: whereBetween on an unindexed column turns a filtered index view into a table scan. Confirm composite indexes exist on (tenant/scope columns, filtered column) before enabling on large tables. This is the most likely production regression and it will look like the package's fault.

Failure modes.

• Blank filter panel — asset not published or Nova major mismatch; silent, discovered by users.
• Silently wrong results — string vs numeric comparison, date/timezone drift, min > max returning empty sets.
• Partial-bound handling — one-sided ranges degrading to >= null style predicates.
• Query planner regression — missing index on high-row-count tables.
• Composer conflict — stale version constraint blocking a Laravel/Nova upgrade.

Each is cheap to prevent with one integration test on the generated query plus one UI smoke test.

Ramp-up. Negligible for a Laravel/Nova-fluent engineer — hours. The cost is not learning the package; it is the decision overhead of carrying an archived dependency and the discipline to fork it the moment the first patch is needed.

Recommendation. Do not adopt as a live Composer dependency. Treat it as reference implementation: spike it, then vendor the code or reimplement against Nova's filter API. The opportunity signal (6.81) reflects a real gap — Nova lacks a polished range filter — but this package's adoption profile (1 star, 0 dependents, archived) means we are buying a starting point, not a maintained component.