Nova Range Filter Laravel Package

Product Decisions This Supports

• Closing a back-office parity gap without spending roadmap budget. "Orders between $100 and $500," "stock below reorder threshold," "signups in the last 30 days" are table-stakes asks in internal ops, support, and finance tooling. This package ships that capability as a micro-slot-in — roughly a day of engineering plus a day to harden — so the team stays on customer-facing work while the internal tool stops being a bottleneck.
• Framing the real choice as build vs. buy vs. fork, with buy-and-fork as the answer. A 5-star, 0-dependent MIT package is not a strategic dependency; it is a shortcut. The explicit decision is "we vendor this small piece of code and own it" versus "we spend half a day to two days writing an equivalent Nova filter ourselves." Both are defensible. Drifting into "we composer require it and hope" is not, because there is no maintainer signal to warn us when a Nova upgrade breaks it.
• Cutting support toil as a measurable lever. Every range filter shipped is a class of "can you pull all orders over X" tickets that never gets filed. Worth instrumenting before/after if the business case needs to survive a quarterly review — this is one of the few admin-panel improvements whose payoff shows up in support queue volume rather than in a dashboard nobody opens.
• Sequencing a small bet now. Low risk, low cost, unblocks a support-triage or reporting workflow this sprint. A good fit for a "small bets" allocation where the alternative is waiting three months for a slot on the platform team's calendar.
• Standardizing internal admin UX. If more than one Nova panel is in play, adopting a single consistent "between X and Y" interaction across resources is a small but real consistency decision for the people who live in these tools all day.
• Forcing a vendor-risk policy answer. Adopting this requires an explicit position on unmaintained micro-dependencies in the admin stack, and — more importantly — a named internal owner of the fork. That ownership question, not the filter itself, is the actual product call. If the org cannot answer "who owns this in twelve months," the honest outcome is to fork on day one or skip it, not to adopt and forget.

When to Consider This Package

Consider it when:

• You are already on Laravel Nova and need numeric or date range filtering that Nova's native filters handle poorly. Outside Nova this has zero value — the first and cheapest filter to apply.
• Scope is genuinely small: one or two internal resources, admin-only users, non-critical paths. This is not a customer-facing component and should not be pitched as one.
• Engineering is willing to read the source end to end (it is small, and MIT makes forking a five-minute decision), pin the version, and vendor it into the repo.
• The filter is a nice-to-have that unblocks a workflow today, and eng bandwidth is tighter than the cost of hardening a fork.
• You want a reusable pattern across several range filters — price, weight, quantity, age — without commissioning a Vue component each time.

Look elsewhere when:

• You are not on Laravel Nova.
• You need an SLA, vendor support, or a formal security review. A 5-star, 0-dependent package offers no maintenance guarantee, and upstream is dormant.
• You need richer filter UX: saved ranges, multi-field boolean builders, shared filter presets. Evaluate broader Nova filter suites or scope a dedicated filter card.
• You are on a Nova major version the package was not built against. Version drift is the dominant failure mode and there are no community signals to warn you — it simply stops rendering or stops applying. Fork the class into app/Nova/Filters rather than debugging abandoned assets.
• The requirement is date-only filtering that Nova's built-in date filters already cover, or where date-picker UX plus correct end-of-day and timezone handling matters. This two-input control will not give you that.
• Your org has a standing policy against unmaintained transitive dependencies. Reimplement — the logic is small enough that this is a legitimate choice, not a cop-out.

Get answers to these before committing:

• Which Nova / Laravel / PHP versions are supported, and when was the last release?
• Does it ship compiled assets, or does integration require a Node build against Nova's toolchain? That answer moves the estimate from hours to days.
• How does it handle empty ranges, NULLs, single-sided bounds, decimal precision, date boundaries, and timezones?
• What SQL does it generate, and will those queries hit an existing index on the filtered column? A range filter on an unindexed multi-million-row table is a full scan every time a user touches an input.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed micro-component that adds min/max range filtering to our internal admin panel. License cost is zero; integration is roughly a day of engineering, plus a day to harden. The payoff is that support and ops can slice data themselves — filtering orders, inventory, or signups by range — instead of filing engineering requests, which cuts toil and speeds up triage. Risk is low if we own it: upstream is unmaintained with minimal adoption, so we vendor it into our repo, pin the version, add a smoke test, and assign an internal owner by name. We are not betting on the maintainer; we are buying a shortcut and taking responsibility for it.

For engineering: Small, single-purpose Nova filter. MIT, easy to read end to end, and the apply() logic is trivial to inspect and override. Recommendation: vendor it rather than requiring it from Packagist, verify the laravel/nova constraint against our Nova version first (ten-second check, most likely reason it will not work), and treat the fork as ours. Confirm whether dist/ ships compiled — if it does, there is no frontend build step and the estimate holds; if not, we own a Vue build against Nova's toolchain. Main pitfalls to cover in the fork: empty strings arriving as '' rather than null (coerce with is_numeric or filled), whereBetween being inclusive on both ends, unqualified columns colliding with joins, datetime truncation excluding the last day, NULLs never matching any bound, and unindexed columns turning every filter interaction into a full scan. Add apply() unit tests on ->toSql() for both-bounds, min-only, and empty cases before shipping.