Custom Date Filter Laravel Package

Technical Evaluation

Architecture fit

• Laravel Nova filters are a first-class, narrowly-scoped extension point: a subclass of Laravel\Nova\Filters\Filter implementing apply(Request $request, $query, $value) plus an options()/UI component. A "custom date filter" is therefore one of the lowest-risk package categories in the Laravel ecosystem — it hooks the Nova index/lens query builder only.
• Blast radius is confined to the admin surface: no writes, no auth, no public request path, no service provider wiring beyond Composer auto-discovery. It cannot corrupt data; worst case it returns wrong or unfiltered rows in an index view.
• Fit is high architecturally but low uniqueness: Nova 4+ ships Nova::dateFilter() out of the box, and the davidhemphill/nova-date-filter-style packages are common. This package must justify itself against a two-line built-in.

Integration feasibility

• Trivial effort: composer require keizah7/custom-date-filter, then add the class to a resource's filters() array. Expect a {start, end} or ['from' => ..., 'to' => ...] payload passed to apply().
• Two open questions materially affect feasibility: (1) is the filter value shape documented, and (2) does apply() use whereDate() or whereBetween() — the former defeats indexes on a datetime column.
• No evidence of a tagged release, CI, or test suite. Assume you will be reading the source before trusting it (it is likely a single small class, so the audit cost is minutes, not hours).

Technical risk

• The dominant risk is provenance, not code: 0 stars, 0 dependents, single author, no community. There is no signal that the package survives the next Laravel/Nova major version.
• Metadata inconsistency worth flagging: the Composer name keizah7/custom-date-filter does not match the repository name nova-date-filter. For a 0-adoption package this is a supply-chain hygiene smell — verify the source URL in composer.json actually resolves to the GitHub repo you think it does before installing.
• Nova version coupling is the real technical risk. Nova is closed-source and paid; the Filter contract is stable-ish but the key/options/default semantics and Vue filter components shifted between Nova 3, 4, and 5. An unpinned or dev-only stability constraint means composer update can silently break admin filtering.
• Timezone handling is the classic defect in date filters: whereDate against a UTC column with a non-UTC app timezone produces off-by-one-day results around midnight.

Key questions

1. What does this do that Nova::dateFilter() (Nova 4+) or a 40-line local filter does not?
2. Which Nova major versions are supported, and are the constraints explicit in composer.json?
3. Is there a tagged, stable release, or only dev-master?
4. Does apply() use whereDate, whereBetween, or raw where — and how are partial/null ranges handled (exception vs. full table scan)?
5. How are timezones resolved — app config, Nova user config, or UTC-only?
6. Is the license declared, and is the author reachable?

Integration Approach

Stack fit

• Assumes Laravel + Nova with Composer. Zero footprint on the public application; no shared abstractions are introduced. It sits alongside your other Nova filters and is removable in one line.
• Because the surface is one class, this is a vendor-and-own candidate rather than a dependency candidate. The pragmatic recommendation for a TPM: budget 60–90 minutes to copy the filter into app/Nova/Filters/CustomDateFilter.php, attribute the source, and drop the Composer dependency. You retain the behavior, eliminate the maintenance and supply-chain exposure, and can fix the whereDate/timezone issues yourself.

Migration path

• If already adopted: no migration needed — filters are additive and reversible. Removing the package requires only deleting the entry from filters().
• If not yet adopted: spike on a branch, read the class, decide fork-vs-depend, then proceed. Do not adopt an untagged 0-star package you have not read; the read cost is lower than the dependency cost.

Compatibility

• Validate composer.json require constraints against your exact laravel/framework and laravel/nova versions before installing. Nova constraints are frequently the blocker.
• Confirm PHP 8.1/8.2/8.3 compatibility and absence of deprecated dynamic properties.
• Check the Composer repositories/source URL matches the GitHub repo — see the name mismatch above.

Sequencing

1. Branch spike; install with --prefer-dist and inspect the class.
2. Register on a single low-traffic Nova resource.
3. Validate generated SQL on a large table (->toSql() / explain), specifically checking for index usage and day-boundary behavior at 00:00 and 23:59 in your app timezone.
4. Decide: fork into app/Nova/Filters/ (recommended) or pin the exact version with a lockfile.
5. Roll out to remaining resources; document the filter value shape in the team wiki.

Operational Impact

Maintenance

• Effective maintenance burden falls on your team. With 0 stars and 0 dependents there is no upstream patch velocity; expect to own every future Laravel/Nova compatibility fix. A forked-in-repo copy makes that ownership explicit and cheap; a Composer dependency makes it implicit and occasionally urgent.
• Pin the version exactly and let Renovate/Dependabot surface it. Expect a permanent "unmaintained" flag in dependency-review tooling, which will require a documented exception.

Support

• No support channel: no issue triage history, no changelog, no docs beyond a README. Internal documentation of the filter's accepted value shape is mandatory, otherwise the next developer reverse-engineers it.
• Escalation path is the source file. This is acceptable only because the source is tiny.

Scaling

• Watch the query, not the package. whereDate() on a datetime column forces a full scan on large tables; on a million-row Nova index this becomes a p95 latency problem that looks like "Nova is slow." Prefer half-open interval predicates (where('created_at', '>=', $start)->where('created_at', '<', $endExclusive)) so the index is usable.
• Filter values serialize into the Nova index query string, so wide adoption increases URL variance — negligible with Nova's default non-cached index, but relevant if you front Nova with a CDN or cache.

Failure modes

• Silent wrong results: timezone drift or whereDate semantics produce off-by-one-day filtering that no one notices until a report disagrees with the UI.
• Silent no-op: a Nova major upgrade changes the filter payload, apply() receives an unexpected shape, and the query degrades to unfiltered — worse than an error, because it looks like it works.
• Install failure: dev-only stability or a stale constraint blocks composer install on a clean checkout, breaking CI for unrelated PRs.
• Provenance risk: the package-name/repo-name mismatch means a typo or a repointed source could pull different code than reviewed. Audit once, then vendor.

Ramp-up

• Near zero for any Laravel developer — Nova filter registration is in the framework docs, and the class itself is a few dozen lines. Onboarding cost is dominated by reading Nova's filter documentation, not this package.
• Documentation you must write yourself: accepted value shape, timezone assumption, which resources use it, and whether it is a fork or a dependency.

TPM recommendation: treat this as a ~90-minute source-reading and fork exercise, not a dependency decision. The architectural risk is negligible; the provenance and longevity risk is real but entirely avoidable at near-zero cost.