Nova Range Input Filter Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. A numeric min/max range filter (price bands, stock thresholds, order totals, score tiers) is commodity UI. The real decision isn't "should we build a filter" but "do we accept a small MIT dependency instead of spending 1–2 engineer-days hand-rolling a Vue + PHP filter." For ops-facing screens with no revenue surface, that's a clean time-save.
• Feature enablement for internal users, not customers. Unlocks self-serve narrowing for support, ops, and finance — "show orders between $50–$200" — without committing to a custom report builder or a BI tool. Scope it as an internal UX improvement with no customer-facing surface.
• Roadmap hygiene / delegation of low-differentiation UI. Reinforces that low-value admin surfaces can be sourced rather than built, preserving engineering cycles for revenue-facing work. Book it as a tactical utility, not an initiative — it will not move product metrics.
• Marginal support for standardizing on Laravel Nova. The ecosystem has commodity components that would otherwise get hand-rolled. This is not a reason to choose Nova and must not factor into that larger platform bet.
• Risk accounting as a maintenance line item. v1.1.0 (Nova 4 compatibility plus assorted fixes) modestly lowers the carrying cost of this dependency. It reduces abandonment risk; it does not resolve it.
• Scoping signal for adjacent asks. Because this is an input filter and not a reporting layer, it gives a natural line to say "no" to histogram, faceting, and multi-field exploration requests — those are separate, larger bets.

When to Consider This Package

Adopt when:

• You are already on Laravel Nova — the hard prerequisite; there is zero value outside it.
• The requirement is a single-field numeric range filter on a resource index (price, quantity, score, threshold) with no aggregation, charting, or faceting.
• You are on Nova 4 specifically and pin to v1.1.0 or later, the first release in the current Nova generation (PR #39, Nova 4 support plus bug fixes). Retire any v1.0 pin.
• You want to avoid authoring and maintaining a custom Vue + PHP filter for a low-value admin screen.
• You are comfortable with a vendor-and-fork posture — MIT license means the code can be copied in-house if upstream goes quiet.

Look elsewhere when:

• You are not on Nova, or are still evaluating Nova alternatives — this must not influence that decision.
• You are on Nova 5 or planning an imminent upgrade — support is unconfirmed and you would likely be writing the compatibility patch yourself. Do not force the install with --ignore-platform-reqs; evaluate forking instead.
• You need multi-field ranges, histograms, faceted filtering, or analytics-style exploration — this is a filter input, not a reporting tool.
• You require maintained dependencies, SLAs, or formal security review. One tagged release, single maintainer, one outside contributor, 17 stars, zero downstream dependents, and a long gap before v1.1.0. Treat abandonment risk as reduced, not resolved.
• Writing it yourself is cheaper than the due-diligence and review cost — realistically 1–2 days for a Nova-fluent engineer.

Two product-level caveats worth carrying into the decision: the changelog for v1.1.0 says only "Fix various issues," so bound inclusivity and NULL handling must be re-verified rather than inherited; and whereBetween is inclusive on both ends and drops NULLs — confirm that matches the product's definition of "in range" before shipping it to a revenue-adjacent screen.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed filter component for our internal admin panel. It lets ops and support staff narrow records by numeric ranges — price bands, quantities, thresholds — in a few hours of integration instead of a few days of custom development. The project just shipped a maintenance release adding support for the current version of our admin framework and fixing outstanding bugs, which is a meaningful de-risking signal for a package this size. It touches only internal tooling, never the customer-facing product, and it's small enough to replace in a day if it stops working. Recommendation: treat it as a tactical utility, not a strategic dependency — proceed, pin the version, and keep the insourcing estimate on file.

For engineering: It's a drop-in Nova filter — one PHP filter class plus a Vue range-input component — implementing Nova's existing filter contract. Target v1.1.0 (PR #39), which adds Nova 4 compatibility and assorted fixes; retire any old v1.0 pin. All correctness lives in apply(), not the UI, so write the min-only, max-only, both, and empty branches explicitly and guard the value shape with data_get(). Caveats to carry: single maintainer, one outside contributor, no declared Nova 5 support, and an opaque "various issues" changelog — re-verify bound inclusivity and NULL handling rather than inheriting prior assumptions. Pin the version, smoke-test against our exact Nova 4 minor, index the filtered column, and plan to own the code (fork or vendor) if upstream goes dormant; MIT makes that clean. If the ownership burden feels disproportionate, replicating the component remains roughly a day of work.