Product Decisions This Supports
- Market expansion into Iran / Persian-speaking segments. The package is a Filament form field that swaps the Gregorian date input for a Jalali (Persian) calendar. That is the minimum viable localization requirement for any admin surface where operators or customers enter dates — birthdates, delivery windows, subscription start/end, invoice and contract dates. It directly unblocks an "Iran-ready admin panel" roadmap item rather than an abstract i18n initiative.
- Build vs. buy vs. fork on calendar UI. The realistic options are: hand-roll a Jalali picker on top of Alpine/flatpickr (2–6 weeks of eng plus ongoing calendar-math edge cases), adopt a maintained JS library and wire it into Filament manually, adopt this package, or vendor/fork it. This assessment is the input to that decision; at 24 stars, a single maintainer, and no release since April 2023, the decision is really "adopt-and-fork" vs. "build."
- Admin stack standardization. If Filament is a candidate for internal tooling, the availability of a Persian date field at near-zero cost removes one objection from the Filament-vs-alternatives evaluation for teams with Iranian operations, support, or finance staff.
- Scoping the localization surface honestly. A date picker is not a date system. Persian users also expect Jalali rendering in tables, exports, PDFs, reports, and API payloads, plus correct handling of the Tehran timezone and the Persian new year boundary. Adopting this package fixes exactly one of those layers — that distinction should shape the localization epic's scope and estimate, not be glossed over.
- Prioritization signal. The high opportunity score against a low maturity score is the classic underserved-niche shape: real demand, thin supply. That argues for treating this as a capability we own, not a dependency we inherit — i.e., budget a small internal fork rather than a "just add the composer package" ticket.
When to Consider This Package
Adopt it when all of the following hold:
- The admin surface is Filament-based (Laravel + Livewire). This is a Filament plugin, not a general-purpose Laravel date picker — outside Filament its value drops to roughly zero.
- The Filament major version is compatible. Verify the
composer.json constraint against your installed Filament version before committing; the last tagged release predates recent Filament majors, so a v4 panel will likely require a fork or a patch.
- You need date entry only — a form field for Persian users — and you already handle Gregorian↔Jalali conversion and Jalali display elsewhere in your stack (or don't need it yet).
- Your team is comfortable owning the code. MIT plus a small, single-file-ish plugin means the fork cost is low; treat the repo as a starting point, not a maintained upstream.
- You can accept a single-maintainer, no-SLA dependency in a non-critical path. Internal ops tooling: fine. A regulated, audited, or customer-facing date-of-birth field with legal significance: pin the fork and add your own tests first.
Look elsewhere — or build — when:
- You are not on Filament, or you need a date picker in Blade/Livewire forms, Vue/React frontends, or public-facing pages. Use a maintained JavaScript Jalali library (e.g. a jalali-moment-style or dayjs-jalali wrapper) and integrate at the presentation layer instead.
- You need Filament v4 / current major support, or you need a release cadence and security responsiveness. No release since 2023-04-26 and zero dependents mean no downstream pressure to keep it current.
- You need more than a picker: Jalali date ranges with fiscal-year presets, Persian digit input normalization, Hijri or multi-calendar support, recurring schedules, or timezone-correct handling around the Nowruz boundary. This package does not claim that scope, and stretching it is more work than a clean build.
- Your compliance posture forbids unvetted, unmaintained third-party code in the request path — in which case vendor it under your own namespace with tests, or don't use it.
How to Pitch It (Stakeholders)
To executives: We need Persian calendar date entry to serve Iranian users in our admin tooling, and today we have nothing. This MIT-licensed plugin gives us that field for effectively zero license cost and a few days of integration instead of an estimated multi-week build. My recommendation is to adopt it as a starting point we fork and own, not as an ongoing dependency — it is a one-person project with no releases in over a year, so we should not plan on upstream support. Net: it buys us speed to market in a niche with real demand and almost no supply, at the cost of a small, bounded maintenance commitment we control.
To engineering: It's a Filament form-field plugin for Jalali date input. Before we take it: confirm the Filament major-version constraint, confirm conversion correctness and Persian-digit handling against our fixtures, and check timezone behavior around the Nowruz boundary. Plan to vendor it into our namespace with tests rather than track upstream — 24 stars, zero dependents, last release April 2023 means we are the maintainers from day one. Scope check: it solves date entry only; Jalali rendering in tables, exports, and APIs is separate work and should be estimated separately in the localization epic.
The ask: Approve a timeboxed spike — one admin panel, one sprint — to fork, test, and integrate. Success looks like Persian operators entering Jalali dates natively with no manual conversion, and a forked package we can patch in an afternoon. If the version compatibility or the date-math tests don't hold up, we fall back to a JS-layer picker and we've lost a sprint, not a quarter.