Nova Date Range Field Laravel Package

Product Decisions This Supports

• Admin/reporting feature delivery. If our internal back office runs on Laravel Nova, this field gives us start/end date filtering on any resource ("orders in the last 30 days," "signups between X and Y") without commissioning a custom Vue component.
• Build vs. buy. It replaces an estimated 1–3 days of design, implementation, and QA on a bespoke Nova field — including the fiddly parts: persistence format, display formatting, null/partial-range handling.
• Roadmap sequencing. It unblocks "table stakes" filtering work on internal dashboards, finance/ops reporting views, and support lookup tooling, freeing engineering time for work that's actually differentiated.
• Scope triage. It draws a clean line between "admins need a date filter" (quick admin win — use this) and "customers need analytics date controls" (product-grade picker, saved ranges, timezones — do not use this).
• Dependency strategy. It's a concrete data point in the "stay on Nova vs. build a custom admin" conversation: how much of our admin UX is held together by small, single-maintainer packages, and what would it cost to replace them.
• Nova upgrade planning. v5.0.0 confirms Nova 5 support, so this is no longer a blocker in a Nova 4 → 5 migration of our admin surface. Version 5.x now tracks the Nova major, so the package is at least being kept alive in step with the framework.

When to Consider This Package

Consider it when:

• We are already committed to Laravel Nova — and specifically on Nova 5, which v5.0.0 adds support for (earlier 1.x releases fit Nova 4).
• The surface is internal/admin-only.
• The requirement is a plain start/end date range — not relative presets ("last quarter," "year to date"), comparison ranges, or timezone-sensitive logic.
• Speed matters more than dependency hygiene, and the blast radius is small enough that forking is cheap.
• We want to avoid adding a heavier dependency (or a second date library) for a single widget.

Look elsewhere — or build in-house — when:

• We are not on Nova. The package has no value outside that ecosystem.
• Adoption signal matters. Still ~3 stars, 0 dependents, a single maintainer plus two one-off contributors, and a low health score. There is no community backstop. Treat it as sample code with a composer.json, not an ecosystem-standard dependency. The 5.0.0 release is a positive maintenance signal, not a change in that verdict.
• We need an SLA, security review trail, or enterprise support.
• The date range is customer-facing or revenue-critical (billing periods, compliance reporting). Buy or build something with a maintenance commitment.
• Requirements exceed a simple range — recurring periods, saved segments, multi-resource filters — because we'll be extending it anyway, and then we own it regardless.

If adopted, mitigate: read the source (it is small), pin the exact version — the jump from 1.0.6 straight to 5.0.0 signals the version number now mirrors the Nova major (à la nova-* packages), not a conventional semver contract, so a loose ^ constraint is a real upgrade risk — and pre-commit to vendoring it into app/Nova/Fields if it becomes load-bearing.

How to Pitch It (Stakeholders)

Executives: "This is a small, free add-on for our admin panel that gives us date-range filters out of the box. It saves roughly a day or two of engineering per reporting screen and lets us ship internal dashboards sooner at effectively zero cost. The latest release adds Nova 5 compatibility and a bug fix, so it's actively kept in step with our framework upgrade path and won't hold up that migration. The risk is still low because the code is tiny and we can copy it in-house if the maintainer walks away — but it remains a single-maintainer project with almost no adoption, so treat it as a utility, not a strategic platform dependency."

Engineering: "Drop-in Nova field for from/to filtering. Integration is a composer require plus a few lines in the resource — it's a thin PHP field class and a Vue component, so there's no meaningful surface area to learn. v5.0.0 adds Nova 5 support (PR from a new contributor) and fixes an undefined-array-key bug on partial/empty input, which tightens the null/partial-range handling we'd otherwise have to QA ourselves. Caveats: ~3 stars, 0 dependents, one maintainer plus drive-by contributors, unclear runway, and the version jump to 5.0.0 means the version number tracks the Nova major rather than semver — pin the exact version so a Nova bump doesn't silently pull breaking changes. Recommendation: review the source before merging (it's a short read), and if it becomes load-bearing, fork it into our namespace so we're not one abandoned repo away from a broken admin filter. Worst case, replacement is an afternoon."