Nova Date Range Filter Laravel Package

Product Decisions This Supports

• Internal-tooling roadmap triage. This package addresses one recurring, low-glamour request: letting ops, support, and finance filter any Nova resource by an arbitrary start/end date rather than a fixed "last 7/30 days" preset. It is the difference between "show orders between Black Friday and Cyber Monday" being a self-serve dropdown and being an engineering ticket. Use it to size that backlog item honestly — if the ask keeps recurring, the answer is a small in-house filtering component, not this dependency.
• Build vs. buy, settled on the "build" side. With 35 stars, zero dependents, and a single release dated 2021-09-28, this is prior art, not a supplier. The realistic options are vendor-and-own versus write a ~60-line filter in-house; both cost hours. A PM decision here is mainly about avoiding the third, worst option — adopting it as a live Composer dependency by default and inheriting an unmaintained liability for a feature worth half a day.
• Dependency-policy precedents. This is a clean, low-stakes case study for where the line sits between "community package" and "copy the snippet." Use it in dependency-review discussions and in an ADR to set the default: admin-only utilities with no data or security surface get vendored, not depended upon.
• Feature-scope definition. It answers "date range on a single column" only. Anything beyond that — relative ranges like "last quarter," timezone-aware day boundaries, per-user saved ranges, composition with other Nova lenses and metrics — is out of scope and must be specified separately. Knowing what it does not cover prevents an underspecified request from being closed as "done" at adoption.
• Concrete use cases worth validating before committing: bookmarked/shared filtered views (Nova persists active filters in the URL, so a fixed from/to link works without extra work); pairing the range with Nova metrics and lenses so aggregates answer the same from/to question; and standardizing date handling across created_at, published_at, and starts_at/ends_at pairs so one fix lands everywhere at once.

When to Consider This Package

Consider it when:

• The target project is on a Nova 3.x-era release and the native filters genuinely lack arbitrary range selection. Confirm this first — modern Nova ships native date filtering, and if it covers the need, adopting this is a net-negative addition to dependency count.
• The need is admin-only, internal, with no SLA, no revenue exposure, and no audit implications.
• Your team is prepared to copy the filter class into app/Nova/Filters and own it as application code rather than track upstream.
• It is being used as reference for a bespoke filter you were going to write anyway — reading 150 lines of working prior art is cheaper than designing from scratch.

Look elsewhere (or build in-house) when:

• You are on Nova 4 or 5. A 2021 component is almost certainly pinned to Nova 3-era Vue 2 tooling; expect Composer constraint conflicts and asset-build breakage. Treat a version conflict as a clean, fast rejection.
• Dependency policy requires active maintenance, security responsiveness, or a supported-version matrix. A lone 2021 release with zero dependents will not pass review, and should not be argued through it for a feature this small.
• Requirements exceed a simple single-column range: relative ranges, timezone-aware boundaries, saved per-user views, or filters composed with other scopes.
• The filtered column is unindexed on a large table. Admin list views degrade as data grows; that is an independent concern the package does not solve, and verifying the index is your team's job either way.
• The surface carries compliance, audit, or financial-reporting weight. The worst failure mode here — the UI renders but the filter silently no-ops after an upgrade — produces confidently wrong numbers on a screen people trust. That risk is disproportionate to the feature's value on any audited surface.

How to Pitch It (Stakeholders)

To executives: This is a small internal-admin utility that lets operations and finance pull date-bounded views of data themselves instead of filing engineering requests. It is not customer-facing and carries no revenue, compliance, or customer-data exposure — the worst realistic failure is one filter dropdown in an admin panel, contained and invisible externally. The recommendation is to treat it as a pattern, not a purchase: the need is real and recurring, but at 35 stars, zero dependents, and no release since September 2021, it is not a dependency worth carrying. If date-range filtering keeps surfacing across internal tools, fund a small maintained in-house component instead. Cost either way is measured in hours, not weeks — the decision is about which hours.

To engineering: It's a thin Nova filter — a PHP filter class plus a Vue component giving start/end selection and presets, serializing a from/to payload into Nova's filter query string. No models, migrations, providers, or queues. Three things to settle before anyone installs it: (1) verify the current Nova release doesn't already ship equivalent filtering — that is the most likely reason to skip it entirely; (2) assume Nova 3.x pinning and check the composer.json constraints and Vue version expectation against our lockfile, and treat a conflict as a fast rejection rather than something to engineer around; (3) if we proceed, vendor the logic into app/Nova/Filters, drop the Composer dependency, handle the partial-range case (only from or only to supplied), add a test asserting the generated query scope so a future Nova upgrade can't silently no-op the filter, and write a short ADR recording the Nova version it was validated against and the fallback. Budget half a day for a Nova-fluent engineer. Note that investigation will likely exceed the effort of reimplementing by hand — which is itself the argument for going in-house, and should be stated as the decision, not left to drift into the lockfile by default.