Laravel Nova Date Range Filter Laravel Package

Product Decisions This Supports

• Build vs. borrow for admin tooling. The real decision isn't "buy vs. build" — there's no vendor, no support contract, no roadmap, just 16 stars and zero dependents. It's borrow-and-own vs. build-and-own: adopt ~one MIT filter class plus a Vue component that compiles to a whereBetween, or spend a short engineering cycle recreating the same control. Frame it that way and the tradeoff becomes honest.

• Roadmap placement. This belongs in back-office productivity and support tooling. It creates zero customer-facing differentiation and must not be positioned as an analytics or reporting foundation. Mid-cycle on revenue work? Filler. Mid-cycle on ops efficiency? A cheap win worth a day of validation.

• Feature scoping on Nova index screens. It collapses two clunky "from"/"to" inputs into a single range control. Concretely enables: narrowing orders, bookings, invoices, users, and audit logs by created_at / paid_at / shipped_at; support investigation windows; finance reconciliation bounds; compliance review periods.

• Consistency across admin surfaces (the highest-leverage use). Nova metric cards accept a $filters array. Reusing the same filter class on a dashboard card and on a resource index makes "last 30 days" mean the identical thing in both places. That alignment — not the widget itself — is where the product value actually sits. One definition, one meaning, every admin surface.

• Dependency-policy precedent. Adopting an unmaintained single-maintainer package means assuming maintenance ownership. Whatever the org decides here becomes the template for the next dozen stale packages it evaluates. The precedent outlasts the filter.

• Platform hygiene budgeting. Adoption carries a recurring, low-grade tax: compatibility checks at every Laravel/PHP/Nova bump, with high likelihood of hard breakage on Nova 5. Weigh that recurring cost against a one-time in-house build — never against zero.

When to Consider This Package

Consider it when:

• You're already standardized on Laravel Nova for internal tooling and need a simple inclusive range filter on resource indexes.
• Blast radius is low — a broken filter costs ops productivity, not revenue or customer workflows.
• You've proven in a scratch branch, on your exact PHP/Laravel/Nova versions, that Composer resolves, the component registers, and the popover renders. Treat Nova 4/5 compatibility as unproven until demonstrated.
• You're willing to fork the MIT code internally, pin the version, add compatibility tests, name an owner, and wrap registration behind a project convention so swapping it out later is a one-file change.
• What you actually want is a readable reference implementation to copy and adapt, more than a maintained dependency.

Look elsewhere or build in-house when:

• You need maintained support, security updates, or any guarantee of forward compatibility with future Nova majors.
• Requirements exceed simple inclusive bounds: relative ranges ("last quarter," "YTD"), per-user saved ranges, rigorous multi-tenant scoping, or formal reporting boundaries.
• The filter touches a customer-facing surface or a critical reporting workflow where silent boundary or timezone errors are expensive.
• Your team has a policy against stale or low-adoption dependencies — then this is a clear no, and the honest deliverable is a short internal build ticket.
• You're not on Laravel Nova. Outside that context the package is irrelevant.

PM-level validation checklist before committing:

• Confirm Nova/Vue compatibility — a July 2021 release will very likely not drop into Nova 5 unchanged.
• Log apply() once to confirm the payload shape ({start, end} vs {from, to}, date-only vs. ISO). Do not guess.
• Confirm end-of-day inclusivity — naive whereBetween('created_at', ['2024-01-01', '2024-01-31']) silently drops everything after midnight on the last day. This is the classic "the report is wrong" ticket; catch it before users do.
• Confirm timezone behavior — browsers send naive local dates, the DB stores UTC; "today" can differ for a Sydney user versus a UTC server.
• Confirm nullable semantics — filtering on paid_at makes every unpaid record vanish. Decide explicitly whether that's intended.
• Confirm the date column is indexed and review query plans on representative data volumes.

How to Pitch It (Stakeholders)

To executives: This is a small tactical accelerator for the Nova admin panel, not a strategic investment. It replaces two clunky date inputs with one range picker that ops and support use daily — and if they like it, that's the entire return. The catch: it's unmaintained, has essentially no user base, and will likely break on the next Nova upgrade. So the ask isn't "adopt this package." It's "spend a day validating it, and if it works, adopt it as internal code we own." If leadership prefers not to own outside code at all, the alternative is a comparable in-house build ticket and we lose roughly a day. Either way, no revenue impact, no customer-facing change, and no support contract to negotiate.

To engineering: Treat this as a code donation, not a dependency. It's a filter class plus a Vue component that emits a date range into a whereBetween — roughly ten minutes of reading (src/, resources/js/**/Filter.vue, README.md) to know the whole API surface. Start resource-local on one index screen, verify the compiled SQL and bindings with DB::listen, and check three things on day one: correct bindings, an inclusive end-of-day upper bound, and an indexed column. Those three checks catch nearly every future bug report this filter will generate. Where it earns its keep is reusing the same class on cards and metrics so ranges mean the same thing everywhere; where it needs extension — related-model columns, orWhereNull for nullable dates, timezone normalization — subclass and override apply() rather than patching the shared registration code. Expect asset-pipeline friction on Nova 4+ (Vite vs. Vue 2-era tooling); if the popover is blank or a Vue console error appears, fork and repackage the component against our Nova version rather than debugging the shipped bundle. Put a small factory in front of DateRangeFilter::make(...) so replacing it later is a one-file change, vendor the MIT source, pin it, add compatibility tests, and name an owner. The recurring tax is the compatibility check at every Laravel/PHP/Nova bump — budget it explicitly instead of discovering it during an upgrade.