Nova Persian Date Filter Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova filter — a small class extending Laravel\Nova\Filters\Filter with apply() (mutates the Eloquent query) and options() (populates the dropdown), plus a compiled Vue component for the Nova UI. Architecturally it is a thin, low-surface-area add-on: no service provider wiring beyond package discovery, no schema changes, no middleware, no queue or cache interaction. It assumes the host stores dates as Gregorian in the database and only converts to Jalali for the filter UI and query bounds — the standard and correct pattern. If that assumption holds, the integration footprint is genuinely small.

Integration feasibility. Feasible but conditional on three gates. First, Nova is a paid first-party product with a licensed, versioned API; a Feb-2020 filter predates Nova 4 (2021, Vue 3 + Inertia rewrite) and Nova 5, so the shipped JS assets and filter component contract are almost certainly incompatible with a current Nova install. Second, it depends on a Jalali↔Gregorian conversion library (verta, morilog/jalali, or similar) whose composer.json constraints will likely be pinned to Laravel 6/7-era versions. Third, the repo is dormant since 2020-02-16 with 6 stars and zero dependents — effectively no community validation of edge cases. Net: viable only on a legacy stack or as a fork reference, not as a drop-in on a modern Nova.

Technical risk. High, concentrated in version coupling rather than logic. The date-conversion math is a solved problem (well-tested libraries exist); the risk is that this package re-implements or wraps it without tests, and that the Nova-facing layer is frozen at an old contract. Specific risks: unmaintained code with no CI or test suite, unknown handling of timezone boundaries (a Jalali day does not align to a UTC midnight — off-by-one filtering at range edges is the classic failure), no coverage of range/preset filters versus single-date filters, and no security posture review of the author or distribution. Because it sits inside the admin panel, blast radius is limited to authenticated operators, which lowers — but does not eliminate — supply-chain concern.

Key questions.

• Which Nova major versions does the composer.json constraint actually permit, and does the Vue component compile against Nova 4/5's toolchain?
• Is the Jalali conversion delegated to a maintained dependency, or hand-rolled in the filter class?
• Does apply() translate Jalali input to Gregorian UTC bounds correctly, including start/end-of-day and timezone offset?
• Is this a single-select filter only, or does it support date ranges (the common need for reporting)?
• Given ~200–400 LOC of likely code, is the fork-and-own cost lower than the review cost of an unaudited binary asset?

Integration Approach

Stack fit. Narrow by design: Laravel + Nova admin panel + a Persian-speaking operator base needing Jalali date filtering on a resource index. If the product does not run Nova, or if operators are comfortable with Gregorian input, this package has no role. It is a localization convenience for an internal tool, not a customer-facing capability.

Migration path. Two realistic routes. (a) Legacy adoption: install only if the app is on Nova 2/3 with matching Laravel, pin the package, and accept frozen behavior. (b) Fork-and-replace (recommended): read the filter class as a specification, then reimplement as a first-party Nova filter on the current Nova version, delegating conversion to a maintained library (hekmatinasser/verta or morilog/jalali). The second route converts an unmaintained dependency into ~1–2 days of owned code with tests, and removes the upgrade cliff entirely. Avoid a hard fork of the upstream repo unless you intend to maintain the JS asset build.

Compatibility. Treat Nova major version as the binding constraint, then Laravel, then PHP. Validate by attempting composer require in a scratch branch and inspecting the resolved constraint graph before any code review. Frontend compatibility is the quiet blocker: a 2020 Vue 2 filter will not render in Nova 4+ without a component rewrite, regardless of what Composer accepts.

Sequencing.

1. Confirm Nova license and exact installed version; read the package composer.json constraints.
2. Spike in a disposable branch: install, load a resource index, verify the filter renders and that a Jalali selection returns the expected Gregorian rows.
3. Run a boundary test — filter a known date and confirm rows at 00:00 and 23:59 local time are included exactly once.
4. Decide adopt vs. reimplement based on spike outcome and the size of the delta.
5. If reimplementing, write feature tests around conversion and range bounds before wiring the UI.

Operational Impact

Maintenance. Effectively zero upstream and full ownership downstream. No commits since 2020, 6 stars, no dependents — there is no community to absorb a Nova or Laravel breaking change. Budget for this as vendored code: your team owns bug fixes, Nova upgrades, and the JS asset rebuild. The one mitigating factor is size; a small surface is cheap to own, which is why reimplementation is competitive with adoption.

Support. None. No issue triage, no security advisories, no release cadence. For an admin-only surface the security exposure is modest, but the absence of any maintainer response means a discovered bug is yours to fix on your timeline. Vendor risk here is not "will they raise prices" but "will they ever ship a patch" — the answer is no.

Scaling. Query-level impact is negligible: the filter adds a whereBetween on a date column, so performance is governed entirely by whether that column is indexed in the host schema, not by the package. Conversion happens in PHP per request, not per row, so cardinality is irrelevant. The scaling concern is organizational, not technical — every Nova upgrade becomes a manual compatibility audit.

Failure modes. Most likely: filter silently absent or throwing on a Nova upgrade after the component contract changes. Second: off-by-one date results at timezone boundaries, which is insidious because it looks like a data problem rather than a filter bug and erodes operator trust in reporting. Third: Composer resolution failure when the pinned Laravel/Nova constraints collide with the rest of the dependency graph. Fourth, low probability but worth naming: unvetted third-party code inside an authenticated admin panel.

Ramp-up. Low for any Laravel developer — the filter API is simple and the codebase is small enough to read in an afternoon. The real ramp-up cost is the investigation to determine whether the package works at all on the current stack; that spike, not the integration, is the dominant effort. Recommend a strict time-box on evaluation (half a day) with a pre-committed fallback to in-house reimplementation, and do not let a "it installed successfully" result substitute for the boundary-date test.