Filament Thai Date Picker Laravel Package

Technical Evaluation

Architecture fit. phattarachai/filament-thai-date-picker is a thin presentation-layer extension for Filament form fields, adding Buddhist Era (BE) year rendering and Thai-localized date/time picking. It carries no persistence, queue, or service-layer concerns — it formats and captures a value that Laravel/Filament already stores. That keeps the blast radius small and makes it a low-ceremony fit for any Filament panel serving Thai users.

What changed in v4.1.0.

• New hard constraint: requires filament/forms >= 5.10.1. Projects on older Filament 5 must remain on 4.0.x. This converts the package from "drop-in" to a coupled dependency on Filament's minor version line.
• Feature: displayFormat() now honours BE years (e.g. 11 ตุลาคม 2569). Defaults unchanged (j M y, j M y H:i), so existing rendering is not silently altered — a good backward-compatibility signal.
• Fix/refactor: the picker now renders Filament's own markup with Thai patches applied instead of a forked Blade view, and time-only mode (->date(false)) plus date limits now sync correctly with Filament 5.10.1.

Integration feasibility. Composer-level only. No migrations, no config publishing required for basic use, no data model impact. The realistic friction is sequencing: we cannot take 4.1.0 without first being on Filament 5.10.1+, and we cannot stay on 4.0.x indefinitely if 4.1.x becomes the maintained line.

Technical risk.

1. Upstream coupling (highest). Dropping the forked Blade view is a maintenance win but a stability trade: the package now depends on Filament's internal markup structure and JS hooks. Any Filament patch release can break picker behaviour without a package version change on our side.
2. Version pin exposure. A >= 5.10.1 floor means a Filament security/bugfix release could force a simultaneous package bump, or conversely a package bump could force a Filament upgrade outside our cadence.
3. Correctness of BE conversion. A +543 year offset applied at display time is easy to get subtly wrong at year boundaries, in exports, in API serialization, and wherever the raw stored value is rendered by other means (tables, PDFs, notifications). Display-only formatting must be confirmed as display-only.
4. Single-maintainer package. Community project, one visible contributor across both changes. Bus factor is a genuine consideration for a field type used in regulated or audited forms.
5. Regression surface of the fix. Time-only mode and date limits were previously broken; teams that worked around those bugs may need to unwind workarounds.

Key questions.

• What Filament version are our panels on today, and what is our minor-version upgrade cadence? Are we already at 5.10.1+?
• Do any forms depend on time-only pickers or min/max date limits — i.e. are we affected by the bugs this release fixes?
• Is BE formatting required only on input widgets, or must it also appear in tables, infolists, exports, and PDFs (where this package does not help)?
• What is the stored value contract — Gregorian date string, Carbon instance, timezone? Does display formatting ever leak into persistence?
• Is there a fallback if the package lags a Filament release (pin Filament, vendor the patch, or revert to native pickers with a Thai locale)?
• Who on the team can validate Thai/BE output, and is that person available for each upgrade?

Integration Approach

Stack fit. Laravel + Filament v5 admin panels, Composer-managed. Fits cleanly as a form-field dependency with no architectural concessions. Best suited to internal admin/back-office panels where Thai date entry is a usability requirement rather than a public-facing concern.

Migration path (4.0.2 → 4.1.0).

1. Confirm current Filament and filament/forms versions across all panels and any shared internal packages.
2. If below 5.10.1, upgrade Filament first and ship that independently — do not bundle the Filament upgrade and the picker upgrade in one change.
3. Bump the picker to 4.1.0 on a branch; run composer why-not filament/forms 5.10.1-style checks to surface constraint conflicts early.
4. Regression-test date, datetime, and time-only fields, plus any min/max date limits.
5. Only then adopt displayFormat() for BE output — as a deliberate, per-field opt-in, not a global default change.

Compatibility.

• 4.0.x remains the supported line for older Filament 5 — acceptable as a short-term holding position, but the support window for 4.0.x is not stated and should be treated as unknown.
• No stated support for Filament 6; assume a breaking major will be required and budget for it.
• Filament 4 and below are out of scope for this release line entirely.

Sequencing recommendation.

1. Now: inventory picker usage (which fields, which modes, which limits) and record current Filament version.
2. Next: Filament 5.10.1+ upgrade as a standalone change, with visual regression on all form fields.
3. Then: picker 4.1.0 adoption; verify the two fixed behaviours resolve any existing workarounds and remove those workarounds.
4. Finally: opt-in displayFormat() per field where BE output is explicitly wanted; leave defaults alone to minimise diff surface.
5. Standing: add picker smoke tests to the Filament upgrade checklist so future Filament bumps don't silently break date entry.

Operational Impact

Maintenance. Net improvement — removing the forked Blade view means we no longer inherit a template that drifts from Filament's own. The cost moves from "template drift we can patch ourselves" to "internal-markup dependency we cannot patch without forking." Ongoing effort is a small, recurring regression-test tax on every Filament upgrade rather than sporadic larger fixes.

Support. Support burden is concentrated in two areas: Filament version-matrix questions ("why can't we install 4.1.0?") and BE formatting correctness reports ("the date shows 2569 but the export shows 2026"). The second is the more damaging class of ticket because it erodes trust in reported data. Document explicitly that BE formatting is presentation-only and enumerate everywhere dates are rendered outside this package.

Scaling. Effectively zero runtime cost — client-side widget behaviour and a formatting call. Scales with the number of Filament panels and form fields, not with traffic or data volume. No queue, cache, or storage implications. The real "scaling" constraint is organisational: every additional panel and every additional Filament upgrade multiplies the regression-test surface.

Failure modes.

• Silent format regression: a Filament upgrade changes markup; the picker renders but dates display or parse incorrectly. Mitigation: automated smoke test asserting a known date round-trips through the field.
• Hard install failure: Composer constraint conflict blocks a Filament security patch. Mitigation: know the escape hatch (temporary fork/pin) before it's needed.
• Locale leakage: BE years appear in exports, APIs, or stored values. Mitigation: assert on persisted value in tests; keep formatting at the widget layer only.
• Abandonment: package goes unmaintained mid-Filament-cycle. Mitigation: keep picker usage isolated to a small number of form classes so reverting to native Filament pickers plus a locale/formatter is a contained change.
• Workaround debt: teams that patched around the time-only and date-limit bugs must actively remove those patches, or behaviour will double-apply.

Ramp-up. Low for any developer already fluent in Filament form schemas — it is a drop-in field with a familiar fluent API, and the unchanged defaults mean existing code needs no edits. The non-obvious skills are (a) Thai/BE correctness review, which needs a Thai-speaking reviewer in the QA loop, and (b) awareness that this is an internal-markup-dependent package, so "it renders" is not sufficient verification after a Filament upgrade. Budget roughly half a day of regression testing per Filament minor upgrade and a one-off day for the initial 5.10.1 + 4.1.0 adoption, including workaround cleanup.