Nova Range Filter Laravel Package

Product Decisions This Supports

• Internal admin tooling, not product surface. A Nova range filter only affects how your own ops/support/CS teams slice records (e.g. price BETWEEN, created_at BETWEEN). It does not touch the customer experience, so it should be scoped as admin DX, not as a roadmap item.
• Feature-level: adds a "from/to" filter widget to a Nova resource's filter panel, replacing manual export-to-spreadsheet workarounds for support triage, back-office segmentation, and threshold exploration (price bands, quantity ranges, date windows).
• Build vs buy: strongly favors build. The package is a thin Filter subclass over Nova's base filter API with a whereBetween — roughly a hundred lines. With 1 star, 0 dependents, and an archived repo, "buy" here means "adopt unmaintained code you will own anyway."
• Roadmap: treat as a low-priority backlog nicety. It unblocks internal efficiency but earns no revenue, retention, or differentiation credit.
• Use cases worth pricing: date-range reporting filters for finance/ops, numeric threshold filters for inventory or pricing reviews, and segment exploration by any numeric attribute in the admin panel.

When to Consider This Package

Consider it when:

• You are pinned to Nova 3 and cannot move to Nova 4/5, where maintained range-filter options and a newer filter API exist.
• You need exactly one narrow thing: a simple numeric or date range filter on a resource.
• You are prepared to vendor or fork the code — because it is archived, you inherit maintenance either way, so read it as reference implementation rather than as a dependency to composer require and forget.

Look elsewhere when:

• You run Nova 4/5 — the ecosystem has moved on; evaluate actively maintained alternatives or implement against the current filter API.
• You need preset ranges ("last 30 days"), timezone-aware dates, multi-range, or relationship-aware ranges. The package is explicitly "simple" by design.
• You care about security patching, issue triage, or community validation: 0 dependents + archived + 1 star means no signal and no upstream support. For anything touching production back-office, prefer code your team wrote or a package with a live maintainer.
• You don't already run Nova — the decision is moot until the Nova adoption question is settled.

How to Pitch It (Stakeholders)

To executives: "This is a tiny admin-panel widget, not a customer feature. It lets support and ops filter records by a numeric or date range instead of exporting to spreadsheets. It's not a differentiator, and the package is archived with essentially no adoption, so the recommendation is a roughly one-day in-house build rather than taking a dependency. No roadmap impact, no vendor cost, no licensing exposure."

To engineering: "Nova 3 range filter — a single Filter subclass with two inputs and a whereBetween. The upstream repo is archived with 1 star and 0 dependents, so treat it as reference code, not a dependency. If we're on Nova 3, copy the filter class into app/Nova/Filters, add tests for empty inputs, inverted bounds, and inclusive/exclusive boundaries, and ship. If we're on Nova 4+, don't adopt it at all — evaluate maintained alternatives or reimplement against the current filter API."