Nova Date Range Filter Laravel Package

Product Decisions This Supports

• Build vs. buy for internal tooling. This package collapses a "do we write our own date-range filter for Nova?" build decision into a one-line dependency decision. A Nova-fluent developer can integrate it in under an hour; the real cost is dependency hygiene, not engineering effort. That makes the buy side clearly favorable for what is, at bottom, an admin-layer convenience.
• Roadmap prioritization and request deflection. "Can we filter the admin by date?" is a recurring, low-glamour request across orders, invoices, support tickets, activity logs, and finance exports. Adopting this lets you close or defer that entire stream and redirect capacity to customer-facing work. Because the package lives entirely in the Nova admin layer, it does not constrain APIs, domain logic, or data modeling — the blast radius of the decision is small by construction.
• Admin UX standardization as a product outcome. The package ships a consistent pattern — presets like Today / Last 7 Days / This Month plus a custom start–end picker — that operators learn once and reuse everywhere. The standardization argument is what gets this adopted across many resources rather than one; per-resource bespoke filters force operators to relearn filtering on every screen.
• International admin readiness. v2.3.0 adds EN, UK, and NL localization at effectively zero integration cost, which supports a decision to widen admin access to Dutch-speaking (and possibly Ukrainian-speaking) operators. Resolve before committing: the changelog's "UK" is ambiguous between Ukrainian (uk) and United Kingdom (en_GB). Do not claim Ukrainian support to stakeholders until that's verified against the lang/ directory.
• Scoping operational risk downward. Because exposure is limited to internal tooling, this can be decided at PM/tech-lead level without architecture review. The dominant product risk is not platform risk — it's silent misreporting: inclusive/exclusive end-date handling and timezone boundaries producing subtly wrong numbers an operator cannot detect by looking at the screen. That risk should be explicitly accepted or mitigated, never assumed away.
• Decision-record inputs. Two facts belong in writing rather than tribal memory: (1) this package is coupled to Nova major versions, so the real forced-upgrade trigger will be a Nova upgrade, not a release of this package; (2) it's a single-maintainer package (13 stars, 0 dependents, no commercial support). Both are acceptable for admin tooling — but only if fork/vendor is a pre-agreed fallback rather than an incident-time discovery.

When to Consider This Package

Consider it when:

• Your internal admin/back-office runs on Laravel Nova and more than one resource needs date-range filtering. Value scales with the number of resources you standardize, not with a single screen.
• You want consistent preset-plus-custom-range behavior across resources and would otherwise build and maintain that component yourself.
• Your operator audience is EN, UK, or NL — and you've validated which locale "UK" actually resolves to.
• You can assign clear ownership of Nova dependency hygiene: someone owns the admin panel and will re-verify the filter on each Nova upgrade.
• You want a low-commitment, reversible decision. Installation is a Composer require plus a filters() registration line; rollback is a downgrade or deleting that line. Nothing is destructive, and no domain or API code depends on it.

Look elsewhere when:

• You are not on Laravel Nova — a general Laravel query/filtering approach is the right tool; this package buys you nothing.
• You need presets, range semantics, or locales beyond what ships and you're not prepared to fork. Timezone-aware range logic, complex multi-field filters, and additional locales are outside the package's surface; there is no config file to lean on.
• You require vendor support or maintenance guarantees. This is bus-factor-1 with no support contract; if an SLA is a hard requirement, that's disqualifying.
• The filtered tables are very large and the date column is unindexed. The filter itself is fine, but query performance is your responsibility — check it against your highest-volume resources (orders, activity logs) and add composite indexes like (status, created_at) where you compose multiple filters.

Gates to clear before committing (PM acceptance criteria):

1. The package's composer.json declares support for your pinned Nova major. Hard gate — do not proceed if your Nova version isn't listed.
2. Locale semantics resolved (uk vs en_GB) and translations verified rendering in staging.
3. Date boundaries tested with real data spanning a DST transition and a UTC-offset boundary — read apply() rather than assuming inclusivity behavior, and confirm a record at 23:59:59 on the end date is included.
4. A named owner for the dependency in your review cadence, plus a line item in the Nova upgrade runbook to re-verify the filter after each Nova major bump.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk, MIT-licensed add-on for our Nova admin panel that gives operators date-range filtering on any resource — orders, invoices, tickets, activity logs, finance exports — without a custom build. The latest release (May 2025) adds English, Ukrainian, and Dutch localization at essentially zero integration cost, widening who can use the admin and reducing misreading for non-English staff. It's a one-line dependency with a trivial rollback, it touches nothing customer-facing, and it lets us close a recurring stream of internal-tooling requests while keeping engineering focused on revenue work.

For engineering: A single-purpose Nova filter — no migrations, no config file, no service-provider work beyond package discovery. v2.3.0 is additive over 2.2.2 (translation files only), so it's a Composer bump with no code change on our side. Integration is a composer require plus a DateRangeFilter::make('Created', 'created_at') entry in filters(). The extension points are narrow by design: subclass and override apply() for query semantics, publish lang/ for copy, and use canSee() for per-role visibility.

What we're explicitly accepting: the end-date and timezone semantics in apply() are our business rule, not the package's — we'll read the source, test boundaries directly against ->toSql() and bindings, and override where correctness matters more than convenience. We're also accepting bus-factor-1 and Nova-major coupling. To keep both cheap, we register the filter in a handful of lines so removal or a vendored fork is a sub-hour operation, and we add a re-verification line to the Nova upgrade checklist. The dominant risk is silent misreporting, not platform failure — and it's mitigated by testing apply() with real data rather than trusting the screen.