Technical Evaluation

Architecture fit

Narrow, single-purpose Nova field: a Vue form component plus a PHP Field subclass that converts between Jalali (Shamsi) and Gregorian for persistence. It has no value outside a Nova admin panel — it is not a general date library, formatter, or API serializer.
Fits cleanly only if Persian-language admin UX is a hard requirement for internal operators. If Persian dates are needed in customer-facing views, APIs, or reports, this package covers none of that and you would need a separate conversion layer (e.g., a maintained Jalali library) anyway.
The correct architecture is: store Gregorian UTC in the database, convert only at the presentation boundary. Any deviation (storing Jalali strings) is a defect to reject at review, not a configuration choice.

Integration feasibility

Mechanically simple: composer require, register the field on a Nova resource, done. The integration surface is a handful of lines per resource.
The real gate is Nova version compatibility. Nova is a commercial product with breaking frontend changes across majors (Vue 2 → Vue 3, revised asset/build pipeline). A release dated 2023-07-26 predates Nova 5 and is unlikely to be compatible without patching. Confirm the composer.json constraint against your installed Nova major before scoping anything.
Nova's license requirement complicates CI: you cannot run the field's test suite or your own integration tests on a public runner without a license. Plan for a private pipeline or manual staging verification.

Technical risk

Silent date corruption is the dominant risk. Off-by-one-day errors at timezone boundaries, Jalali leap-year handling (the 33-year cycle rule, not a simple modulo), and DST shifts are all plausible and all fail quietly. Wrong dates in an admin panel are discovered months later in financial or scheduling records.
Maintenance risk is high. 8 stars, 0 dependents, single maintainer, no release in ~2 years, quality score 0.23. There is no community backstop and no evidence of a maintenance commitment.
Upgrade coupling. You inherit a hard dependency on a third party keeping pace with Nova majors. Nova upgrades are annual; this package's release cadence suggests it will not.
Ecosystem gaps. Unclear whether it participates correctly in Nova sorting, filters, metrics, CSV/Excel exports, and dependsOn containers. Sorting on a rendered Jalali string instead of the underlying Gregorian column produces a plausible-looking but wrong ordering — a common failure in this class of field.
Opportunity signal vs. quality signal. The opportunity score (14.72) reflects a genuine underserved market; the overall score (0.23) reflects that this implementation does not capture it. Treat those as independent facts.

Key questions

Which Nova majors are declared compatible, and does it render under Vue 3 / Nova 5?
Which Jalali conversion library does it depend on (PHP and JS sides), and is that dependency itself maintained?
Does it persist Gregorian and render Jalali, or does it round-trip a string?
How does it resolve timezone — app.timezone, UTC, or browser-local?
Does it support DateTime as well as Date, and does it respect Nova validation rules (after, before, nullable)?
Do sorting, filtering, and export operate on the underlying column or the display value?
Is there a test suite, and are there fixtures for leap years and boundary dates?
What is the license, and is the maintainer responsive to issues/PRs?

Integration Approach

Stack fit

Assumes Laravel + Nova on a licensed install. PHP version, Laravel major, and Nova major must all be pinned and verified — the package metadata alone is not sufficient evidence at this age.
Best fit: internal back-office tooling for an Iranian-market product where operators require Shamsi input. Poor fit: any surface where the date is consumed programmatically by clients.

Migration path

Given the small surface area (one field, one conversion concern), the realistic recommendation is to vendor/fork the package rather than consume it as an upstream dependency. This removes the bus-factor risk, lets you patch Nova compatibility yourself, and costs an estimated 1–3 engineer-days for a Laravel developer familiar with Nova custom fields.
Building in-house from scratch is a credible alternative if the fork proves messy — a Nova date field wrapping an established Jalali library is a small, well-bounded piece of work, and you retain full control of timezone and storage semantics.
Do not migrate existing data. Keep the database Gregorian; the field is presentation-only, so "migration" means swapping the form component on selected resources.

Compatibility

Pin the fork to your exact Nova major and add a CI job (private runner) that boots Nova and renders the field.
Add a compatibility test matrix entry: every Nova upgrade triggers a field regression check. Budget ~0.5 day per Nova major.

Sequencing

Verify Nova compatibility and conversion correctness in a throwaway branch; write failing tests for leap-year and timezone-boundary dates first.
Fork and vendor; strip unused features; pin dependencies.
Pilot on one low-risk resource (e.g., a profile or notes screen) behind a feature flag, with dual display (Jalali + ISO tooltip) so operators can self-verify.
Validate sorting, filtering, and CSV export explicitly on the pilot resource.
Roll out resource-by-resource; keep the flag until each resource is signed off by a Persian-reading operator.

Maintenance

Effective maintenance ownership transfers to your team the moment you adopt it. Expect ~0.5–1 day/quarter of dependency upkeep plus one reactive fix per Nova major.
Track the upstream repo for security or correctness fixes, but do not depend on them arriving.

Support

No vendor, no SLA, GitHub issues only, single maintainer, no recent activity. Escalation path is "we fix it." This must be reflected in on-call expectations and in the risk register.
Internal documentation is mandatory: conversion semantics, timezone policy, and the fork's divergence from upstream.

Scaling

Runtime cost is negligible — a small Vue component and a per-record conversion. No server-side load, no query changes, no caching concerns.
Scales horizontally without thought. The scaling concern is organizational (trained operators, QA with Persian/Jalali literacy), not technical.

Failure modes

Silent date corruption — wrong dates written to the database with no error surfaced. Highest severity, lowest detectability. Mitigate with round-trip tests and dual display.
Nova upgrade breakage — field fails to render, blocking admin access to affected resources. Mitigate with the pinned fork and an upgrade checklist.
Sort/filter/export divergence — UI looks correct, ordering and exports are wrong. Mitigate by testing these paths explicitly, not just the form.
Timezone drift — dates shift by a day near midnight for operators in different zones. Mitigate by fixing an explicit timezone policy and testing boundaries.
Localization gaps — untranslated validation messages or month names degrade operator trust.

Ramp-up

Engineer: ~half a day to be productive, given the small surface area and Nova familiarity.
QA/ops: needs someone who reads Persian and understands the Jalali calendar to validate conversions — this is the real onboarding constraint and should be identified before the pilot, not after.
Budget one sprint end-to-end for a safe, tested, forked rollout on a handful of resources.