Nova Persian Date Laravel Package

Technical Evaluation

Architecture fit. This is a single-purpose Nova field: a PHP Field subclass plus a compiled Vue component that renders a Jalali (Persian) date picker and converts to/from Gregorian for storage. It fits only if Nova is already a licensed dependency in the target application — it has zero value outside the Nova admin surface and does not touch the public-facing app layer. That is a narrow blast radius, which is good for risk containment but also means the package is not load-bearing: any resource using it can be reimplemented in-house for roughly a day of effort. The 0.255 score and 11 stars are consistent with a personal utility published to Packagist rather than a maintained library; treat the score as a prior, not a verdict, and validate the code directly.

Integration feasibility. Mechanically trivial: composer require, then reference the field class in a Nova resource. The real gate is version constraints. With a last release of May 2021, the package predates Nova 4 (Vue 3 frontend) and Nova 5, so its laravel/nova constraint and its Vue 2 component almost certainly will not install or render on a current Nova install. Expect composer to refuse resolution outright rather than fail silently — a fast, cheap signal. Secondary checks: which Jalali conversion library it depends on (and whether that library is itself maintained), whether it stores Gregorian or Jalali in the column, and whether it exposes Nova's standard date affordances (sortable, filterable, nullable, timezone/displayUsing).

Technical risk. Medium-to-high, concentrated in three places:

• Abandonment. Single maintainer, no release in ~4 years, no visible CI or test suite. No security response path, no upstream fixes.
• Frontend coupling. Nova field components compile against Nova's internal tooling. A Vue 2 component will break on Nova 4+; a broken component typically renders blank or throws in the browser, which is a confusing failure mode for non-frontend developers.
• Date correctness. Jalali↔Gregorian conversion has real edge cases: leap-year divergence between the two calendars, midnight boundaries, and timezone offsets. A silent off-by-one on a date field is a data-integrity bug, not a cosmetic one.

Key questions to resolve before committing:

1. What Nova version(s) does composer.json allow, and what is our Nova version today and in 12 months?
2. Are values persisted as Gregorian (preferred) or Jalali? Can existing rows be read back correctly?
3. Which conversion library is the transitive dependency, and is it maintained?
4. Is there any test coverage for leap years, DST, and null/invalid input?
5. What is the license, and are we comfortable vendoring a fork under it?

Integration Approach

Stack fit. Viable only on a Laravel + Nova 3 stack. On Nova 4/5, plan for a fork-and-upgrade or an in-house replacement from the start; do not budget for "it just works."

Migration path. Three options, in order of preference:

1. In-house field (recommended). Build a thin Nova field wrapping an actively maintained Jalali converter, delegating storage and formatting to Nova's native Date/DateTime field. This keeps us on Nova's supported upgrade path and removes the abandoned dependency entirely — likely under a sprint of work.
2. Fork and upgrade. Vendor the package into a private namespace, migrate the Vue 2 component to Vue 3, and add tests around conversion edge cases. Reasonable only if the field has bespoke UI behavior we want to preserve.
3. Use as-is. Acceptable only for a throwaway internal tool pinned to Nova 3 with no upgrade horizon.

Compatibility. Pin exact versions in composer.json; verify PHP 8.1+ compatibility (implicit-nullable and dynamic-property deprecations are common in 2021-era code). Confirm the compiled JS asset in the repo matches the source, since Nova fields ship prebuilt.

Sequencing. (a) Timeboxed spike: install in a scratch Nova app, verify field renders, saves, and re-reads across a leap-year date, a midnight timestamp, and a null. (b) Decide fork vs. in-house based on spike output. (c) If in-house, define the field contract (storage format, timezone, nullability) and write conversion tests first. (d) Roll out to one low-traffic resource before wider adoption.

Operational Impact

Maintenance. Effectively zero upstream maintenance; we own it the moment it ships. Assign a named owner, vendor the code into the repo or a private registry, and add it to the dependency-review list. Budget a small recurring cost for Nova major-version upgrades, which will break any third-party field.

Support. No vendor, no SLA, no security channel. Internal expertise is the only support path — acceptable for a localized date widget, not acceptable if it becomes the entry point for compliance-relevant dates.

Scaling. Runtime cost is negligible; conversion is per-request arithmetic on a single field. The scaling concern is organizational: every additional Nova upgrade requires re-validating an unmaintained frontend component, and that cost compounds as more resources adopt the field.

Failure modes to watch.

• Composer resolves but the field renders blank after a Nova minor upgrade.
• Off-by-one dates on Jalali leap years (e.g., around Esfand 30).
• Date shifts for users in a different timezone than the server, particularly near midnight.
• Invalid or malformed input silently coerced to today's date rather than rejected.
• No validation on the backing column, letting bad data persist for months before it is noticed.

Ramp-up. Low for any Laravel developer — a few hours to a day to use the field, plus a sprint if we fork or rebuild. The cost is not learning the package; it is the institutional drag of owning an unmaintained frontend asset inside a paid, fast-moving admin framework. Recommendation: use the spike to confirm the version wall, then default to the in-house field built on Nova's native date primitives.