Daterangepicker Laravel Package

Product Decisions This Supports

• Whether to add date-range filtering to the admin surface at all. This package exists to answer one narrow question: should our Nova reporting screens, audit logs, and export flows support start/end date filtering? That is a small, reversible feature decision — approve it as a scoped enabler, never as a platform dependency. Nothing downstream should be architected around it.
• Build vs. buy, where the honest answer is genuinely close. The alternative is one to two days of internal Nova field work (Vue component, filter serialization, asset registration) plus permanent ownership of that code. The package is free and already packaged, so the decision must turn on license, maintainability, and verification cost — not on saved hours. Set a rule: if diligence overhead exceeds roughly one engineer-day, build it internally and keep the IP clean.
• Sequencing relative to the Nova 4 → 5 upgrade. Release 0.0.11 is a compatibility-only change (widened laravel/nova constraint, no source edits). That makes this a follow-on to the Nova migration, not a blocker — but only if we verify it independently rather than trusting the constraint bump. Keep the two workstreams separate so a broken admin panel has exactly one plausible cause.
• A dependency-portfolio classification decision. Five stars, zero dependents, a single-line release, no changelog narrative, single maintainer, no stated support policy. That puts it in the "single-maintainer utility" tier: pinned exactly, owned by a named person, reviewed on every Nova major, and excluded from business-critical paths until it matures. Documenting that tier is itself a useful outcome of this evaluation — it gives us a repeatable rule for the next package that looks like this one.
• Blast-radius containment as a legitimate reason to say yes. This lives entirely in the admin plane with no public request path and no customer-facing exposure. That lower exposure is a defensible basis for accepting a pre-1.0 package here, where the same signals would disqualify it in a checkout or API service. Making that asymmetry explicit prevents both over-caution now and inconsistent precedent later.
• A documentation inconsistency that must be resolved before commitment. The repository description describes a generic Laravel Blade component (configurable formats, locale, publishable assets) while the release notes describe a Nova filter. These are different products with different integration stories and different reuse potential. Confirming which artefact actually ships is a five-minute check that determines whether this is useful outside Nova at all — and the fact that we can't tell from the docs is itself a maturity signal to weigh.
• A licensing decision that is commercial, not technical. GPL-3.0 on a Composer dependency will draw legal questions for any closed-source, redistributed, or on-prem-appliance product, and it is atypical for the Laravel/Nova ecosystem (mostly MIT). Route it to legal before engineering starts. If the answer is no, the build-vs-buy decision flips outright and the evaluation ends.

When to Consider This Package

Adopt it when:

• The admin surface is already Laravel Nova, and the specific need is a date-range filter on a resource index, dashboard, or export.
• You are on, or actively migrating to, Nova 5 — the version 0.0.11 targets.
• The context is admin-only and non-critical, where a silent failure costs an operator a page refresh, not a customer a transaction.
• You have (or can cheaply add) one named owner who will re-verify the filter on every Nova major, and a CI smoke test asserting the filter registers.
• Legal has cleared GPL-3.0 for the intended distribution model, and the codebase is not redistributed to clients.
• An index exists on the filtered timestamp column, or the range is capped server-side — otherwise whereBetween will full-scan large tables.

Look elsewhere (or build in-house) when:

• Legal cannot clear GPL-3.0. This is a hard stop, not a trade-off. Replacing one filter is a day of work; unwinding a license obligation in a shipped product is not.
• You are not on Nova. The Blade-component framing in the README is unverified, and there are exactly zero dependents and no test suite — you would be the first real consumer of a path nobody has exercised.
• The range logic must be reused beyond Nova (exports, API endpoints, scheduled reports). The package only supplies the picker/filter; the parsing, timezone normalisation, and inclusive-boundary semantics are yours to own regardless. If you're building that abstraction anyway, the marginal value of the package is a UI component, not a dependency.
• You're mid-Nova-upgrade. Bundle nothing. A constraint conflict here can block the entire Nova bump, and diagnosing two changes at once is exactly the scenario to avoid.
• The need is business-critical or customer-facing. Single maintainer, no support policy, no CI matrix, sub-1.0 versioning — that combination does not belong anywhere revenue depends on it.

How to Pitch It (Stakeholders)

To executives — one paragraph: We're evaluating a small, free, open-source add-on that puts date-range filtering on our internal Nova admin screens. It saves roughly one to two days of engineering versus building it ourselves, and it only touches the admin panel — no customer-facing surface. The two things we need decisions on are not technical: legal must clear its GPL-3.0 license for our distribution model, and we should accept it as a pinned, single-owner utility rather than a strategic dependency. Realistic ask: approve a short, time-boxed trial on one reporting screen. If the license or the verification work doesn't clear the bar, we build the same filter in-house for about a day and own it outright.

To engineering — the framing: The package is a thin wrapper, and its value is packaging, not logic. Our real work is the part it doesn't do: one parseRange() that decides inclusive-vs-exclusive end-of-day and timezone handling, a DateRange value object that the filter, CSV export, and any API endpoint all resolve from, and tests that assert the generated SQL rather than the rendered Vue. Pin the version exactly (0.0.11, no caret), disable auto-merge for it, keep registration in a trait, and subclass to customise apply() — never patch vendor/. Have a VCS fork ready with a repositories entry so "maintainer disappears" is a composer require change, not an incident.

Risk summary to attach to the approval: GPL-3.0 licensing (gating — legal, not engineering); single maintainer with 5 stars and no dependents (mitigated by exact pin + fork fallback + named owner); unverified Nova 5 compatibility (mitigated by staging verification before production); and an unresolved ambiguity about whether the shipped artefact is a Nova filter or a Blade component (resolve by reading the source before planning anything). All four are cheap to test and expensive to assume.