Nova Range Input Filter Laravel Package

Product Decisions This Supports

• Feature scoping for internal admin tooling. This package addresses one specific gap in Laravel Nova: Nova ships Boolean, Select, and Date filters out of the box, but no numeric range filter. If your roadmap includes "filter orders by price band," "filter leads by score threshold," or "filter inventory by stock level," this is a candidate enabler rather than a from-scratch build.
• Build vs. buy vs. vendor. The realistic decision is three-way, not two-way: (a) install the package, (b) write a custom Nova filter in-house (~2–4 hours of a Laravel developer's time), or (c) copy the package's source into your codebase as an internal filter and own it. With zero stars and zero dependents, "vendor the code" is likely the strongest option — you get the implementation without taking a dependency on an unproven single-maintainer package.
• Consistency across resources. A shared range-filter component prevents every developer from hand-rolling a slightly different min/max filter on each Nova resource, which is a real (if modest) maintenance tax on admin panels with 10+ resources.
• Use cases worth validating: e-commerce price/stock filters, CRM lead-score bands, analytics dashboards with numeric thresholds, subscription filters on MRR or seat count, and any resource where users currently sort-and-eyeball instead of filtering.
• What it should not drive: this is not a reason to adopt Nova, not a customer-facing capability, and not an argument for changing your admin-panel strategy. It is a rounding-error-sized line item in an internal-tooling backlog.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova (a paid product), so the addressable audience and marginal cost are both small.
• You need numeric range filtering on more than one Nova resource — the value scales with reuse; for a single filter, writing it in-house is faster than evaluating a package.
• Your team is comfortable reading a small amount of third-party PHP and can fork or patch it if the maintainer disappears.
• You want an MIT-licensed starting point and are willing to treat it as reference code rather than a supported dependency.
• You have verified compatibility with your Nova major version (Nova's filter API has changed across v4/v5) and your PHP/Laravel versions before committing.

Look elsewhere when:

• You are not on Nova. Nova is commercial and opinionated; if you are on Filament, Backpack, or a custom admin, this package is irrelevant — evaluate the equivalent for your stack.
• You need date ranges, which Nova and several established packages already cover; do not stretch a numeric filter to do temporal work.
• You need complex or high-cardinality filtering (full-text, faceted, multi-field) — reach for Laravel Scout with Meilisearch/Typesense or a purpose-built filter suite.
• You require an SLA, security responsiveness, or long-term maintenance guarantees. Zero stars, zero dependents, and a single maintainer mean bus-factor risk is the dominant consideration.
• Your organization has dependency-review gates that a package with no adoption signal will not pass — in which case go straight to vendoring or in-house.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that adds numeric range filtering to our internal Nova admin panel — the kind of "filter orders between $50 and $200" control our ops team currently works around manually. Cost is effectively zero (no license, no procurement) and the upside is a few reclaimed developer hours per resource plus a better internal workflow. The caveat is maturity: the package has essentially no adoption and one maintainer, so I recommend we bring the code in-house rather than depend on it as an external library. That keeps the benefit and removes the risk.

To engineering: This is a thin wrapper over Nova's filter API that gives you min/max range inputs without hand-rolling one per resource. Given the project's adoption profile, the recommended path is to vendor the source as an internal filter — you inherit the implementation and the UX pattern while retaining full control, and you avoid a dependency on a package we cannot lean on for security or version support. Budget roughly half a day to review, adapt, and test against our Nova version; compare that against 2–4 hours per resource to build from scratch, and decide based on how many resources actually need it.