Nova Datepicker Filter Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-tooling surface area. This package is a single Laravel Nova filter that adds a date-picker UI for filtering a resource index by date. The capability is small and self-contained, which makes it a clean build-vs-buy call: adopting it is roughly a "buy" decision worth a few hours of integration, versus building and maintaining an equivalent custom Nova filter in-house.
• Roadmap for internal reporting and ops dashboards. Date-range filtering on Nova resource indexes is usually the first ask when a team starts doing "last 7 / 30 / 90 days" reporting on top of admin panels. This package unblocks that class of feature (orders in period, signups in period, activity in period) without a bespoke filter per resource.
• Scope/effort estimation. Because it is a filter rather than a full reporting layer, it should be scoped as a UI convenience, not as an analytics solution — it does not replace aggregation, exports, or charting work.
• Dependency risk budgeting. Adding it is a third-party runtime dependency in an admin-only surface (low blast radius, low traffic), which is a favourable risk profile compared to a customer-facing dependency. The maintenance cadence and changelog depth noted below are inputs to that call.
• Prioritisation signal from release 1.1.0. The release is a minor, non-breaking improvement to date parsing. That indicates active (if light) maintenance and a focus on correctness of date interpretation — relevant if you operate across timezones or non-US date formats, where ambiguous parsing is a real source of "the dashboard is wrong" support tickets.

When to Consider This Package

Adopt it when:

• You are already running Laravel Nova (a paid, licensed product) and the team is comfortable with Nova's filter API. This package is meaningless outside Nova.
• You need a straightforward date-range or single-date filter on one or more Nova resource index screens and want it live quickly.
• Your users work with dates in more than one format or timezone — the 1.1.0 "improved date parsing" change is the specific reason to prefer this version over 1.0.0.
• Your Nova major version and PHP version are confirmed compatible with the package. Verify this before committing; Nova 4 vs. Nova 5 and PHP 8.x matrix compatibility is the most common adoption blocker for small Nova packages.

Look elsewhere (or build in-house) when:

• You are not on Nova, or you are evaluating Nova alternatives — in that case the filter is irrelevant and the decision is really about Nova itself.
• You need rich date semantics: relative ranges, preset buttons ("Today / This week / Quarter to date"), date-plus-time comparison, null-date handling, or multi-column date logic. A custom filter is typically 50–150 lines and gives you exactly the semantics you need.
• You require vendor-backed support, SLAs, or an audited supply chain. This is a small-scope community package; treat changelog depth and release frequency as diligence inputs.
• The package's date-parsing behaviour cannot be verified against your locale/timezone expectations. In v1.1.0 the change is described in one line only, with detail deferred to the GitHub compare link — read the actual diff and test with your formats (DD/MM vs. MM/DD, ISO, timezone-aware inputs) before rollout.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost add-on for our existing Laravel Nova admin panel that gives the team date-range filtering on internal screens — the kind of "show me the last 30 days" view that currently gets built by hand each time. It costs a few hours of integration rather than a multi-day build, and it lives entirely in the back office, so it carries no customer-facing risk. Version 1.1.0 is a minor update that improves how dates are parsed, which directly reduces the odds of users seeing incorrect date-filtered results; there are no breaking changes and no migration work.

To engineering: Add nova-datepicker-filter at ^1.1.0 and pin it. 1.1.0 is a non-breaking minor release whose only substantive change is improved date parsing — treat it as a correctness fix, not a feature. Before merging, confirm Nova/PHP version compatibility, and add a short test or manual check covering our real-world date formats and timezones so the parsing change is validated against our data rather than assumed. If the filter's semantics don't match what product wants (presets, relative ranges, null handling), the fallback is a custom Nova filter — the package is a convenience, not an architectural commitment, so keep the integration thin and easy to remove.