Inline Date Time Picker Laravel Package

Product Decisions This Supports

• Filament admin/panel UX upgrades: An inline date-time picker removes the extra modal click in date/time entry flows — a small but measurable friction reduction in scheduling-heavy admin screens (bookings, appointments, event publishing, shift planning).
• Filament version roadmap: v2.1.0 adds Filament 5 support, which unblocks teams planning or mid-way through a Filament 4 → 5 upgrade. This is the primary new decision point: it makes the package viable for panels pinned to Filament 5, where it previously wasn't.
• Build vs. buy for form-field ergonomics: Inline pickers are a classic "build it in an afternoon, maintain it forever" trap once you account for timezone handling, locale formats, keyboard accessibility, and Filament's reactive/live() lifecycle. This package is a candidate to buy (adopt) rather than build.
• Feature scoping: Supports roadmap items like "reduce clicks to schedule," "fewer form validation errors on date entry," and "consistent date-time UX across resources."
• Not a decision driver: The two Dependabot tar bumps are transitive dev/tooling hygiene, not product-relevant. Do not treat them as a reason to adopt or upgrade.

When to Consider This Package

Consider it when:

• You are on Filament 5 (or upgrading to it) and need inline date/time entry — this is the specific capability v2.1.0 unlocks.
• Your admin forms have high-frequency date-time entry (scheduling, dispatch, logs, reporting filters) where modal-based pickers cost real operator time.
• You want to avoid maintaining a custom field against Filament's evolving field API — plugin maintenance is now demonstrated across major versions (Filament 5 support landed promptly).
• Timezone and locale correctness matter, and you'd rather inherit a maintained implementation than own it.

Look elsewhere or build in-house when:

• You are on Filament 3 or below, or on a Filament version outside this package's supported matrix — verify the constraint before planning.
• You need date-only or time-only semantics; a combined inline picker may be more control than the use case justifies.
• You have strict third-party dependency policies (security review, vendored code, no external UI deps) — a small single-maintainer plugin may not clear procurement.
• Accessibility certification is a hard requirement (WCAG 2.2 AA audit) and you can't independently verify the picker's keyboard/screen-reader behavior.
• Your date-time needs are exotic (custom business calendars, non-Gregorian systems, fiscal-week logic) where a bespoke field is cheaper than fighting a general-purpose picker.

Adoption caveat from this release: the Filament 5 support is a single PR by the maintainer with no accompanying test-matrix or breaking-change detail in the notes. Confirm the composer.json constraint and run it against your actual Filament 5 panel in a staging branch before committing, especially if you rely on Filament reactive fields (->live(), ->afterStateUpdated()).

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a small open-source Laravel/Filament add-on that replaces the standard click-to-open date/time modal with an always-visible inline picker. The business case is operator throughput and data quality on scheduling-heavy screens — fewer clicks per record and fewer malformed date entries. Cost is effectively zero (no license), risk is low and reversible (it's a form-field swap, not a platform change), and the latest release extends compatibility to Filament 5, which aligns with our panel upgrade path. Recommendation: pilot on one high-volume resource, measure entry time and validation-error rate for two weeks, then decide.

To engineering: v2.1.0 is a compatibility release — Filament 5 support plus two transitive tar dependency bumps. No breaking changes are declared in the notes, but the Filament 5 support is a lone PR without published test coverage, so treat the constraint and reactive-field behavior as unverified until we smoke-test. Integration is a composer require plus swapping the field class in target resources; effort is low and the change is contained to individual forms, so rollback is trivial. Ask: (1) confirm the Filament 5 version constraint, (2) verify it works with our existing live()/dependent-field logic and our timezone config, (3) assess the maintainer-bus-factor and whether we're comfortable with a single-maintainer dependency. If any of those fail, a custom field is a bounded fallback — but budget for ongoing maintenance against Filament's field API.