Time Picker Laravel Package

Product Decisions This Supports

• Admin/back-office form UX (primary use case). Nova is Laravel's paid admin panel; this package is a single-purpose form field for capturing a time-of-day without a date. It supports the "scheduling-ish" surfaces inside internal tooling: business hours, shift and roster windows, appointment slot start/end times, delivery cut-offs, store opening/closing, maintenance windows, quiet hours for notifications.
• Build vs buy — the real decision it informs. The honest framing is not "should we use this package?" but "is a time-only input worth a third-party dependency at all?" A Nova field is typically a few hundred lines of Vue plus a PHP Field class. That makes this a component-level buy/build decision, not a platform bet — hours, not weeks, either way.
• Feature prioritisation. Time-of-day entry rarely unblocks revenue or retention. It is polish on an internal tool. It belongs in the "do it when the surface is being touched anyway" bucket, not as a roadmap line item competing with customer-facing work.
• Roadmap dependency mapping. Any value is contingent on staying on Laravel Nova. If Nova is on a watch list (cost, licensing, or a move to Filament/Inertia), this package's value goes to zero at the same moment — do not let it become a reason to stay.
• Use cases where it does not help, and where PMs most often mis-scope it: timezone-aware scheduling, DST correctness, recurrence rules ("every second Tuesday"), durations and overlaps, conflict detection, availability calendars, or any customer-facing time entry. This is a display/input widget, not scheduling logic. If the requirement mentions any of the above, the field choice is not the decision — the data model is.
• Opportunity signal: low (score ~35, 0 stars, 0 dependents, 0 dependents means no observable production usage). Treat this as an unvalidated artifact. It informs a spike, not a commitment.

When to Consider This Package

Consider it only when all of the following hold:

• You are already committed to Laravel Nova and are not evaluating an exit in the current planning horizon.
• The need is genuinely time-only in an internal, low-blast-radius admin UI — not customer-facing, not regulated.
• You have confirmed the field works with your Nova major version (Nova 4 vs 5 have different front-end conventions; the last release date alone does not prove compatibility). Verify by installing in a throwaway branch and rendering the field on create, update, and detail views.
• You are comfortable reading and, if needed, owning the source: MIT licence permits vendoring and forking, so the mitigation is to copy the field into your app or a private package rather than depend on the repository.
• Someone has done a 30–60 minute read of the PHP and Vue for anything that would fail a basic security review (unbounded input, raw HTML, external asset loads, build artefacts committed).
• The alternative — a native Nova DateTime field configured to show time only, or a small in-house field — would cost more engineer time this sprint than the audit would.

Look elsewhere (or just build it) when:

• You are not on Nova. Filament, Livewire, Inertia/React/Vue, and Blade admin panels each have different, often better-supported options. This package is not portable.
• You need behaviour, not an input. Timezones, DST, durations, recurring availability, validation against a schedule, or slot-conflict logic all live outside a form field. Buy a calendar/scheduling library or model it yourself.
• You need maintenance evidence. Zero stars and zero dependents means no downstream users discovering breakage before you do. No community means every Nova upgrade is your regression test. If your team cannot absorb that, the correct buy is the in-house field.
• One maintainer, one release. A single 2025 release with no issue history is a thin signal. Fine for a prototype, weak for a system with an SLA.
• You need mobile-grade time UX or accessibility guarantees. Unverifiable from the outside; test with keyboard-only and screen-reader passes before shipping to staff who depend on it.

Default recommendation: build or copy a ~100-line Nova field in-house, or configure Nova's native DateTime field for time-only entry, and keep this package as the reference implementation you read for fifteen minutes. If you do adopt it, pin the version, vendor the source, and record an owner and a removal date.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small UI widget for our internal admin tool — it lets staff type a time without a date, for things like opening hours or shift windows. Cost is near zero; so is strategic value. It is not a capability, a differentiator, or a risk to the roadmap. The only real decision is whether to take a dependency on an unmaintained third-party add-on or spend a few engineering hours writing the field ourselves; my recommendation is the latter, because the dependency cost over two or three Nova upgrades exceeds the build cost today. No budget ask, no timeline impact.

To engineering leads (one paragraph): MIT-licensed Laravel Nova time field, single release (Feb 2025), no stars or dependents, so no external validation and no one else absorbing compatibility breakage. It is small enough to audit in an hour and small enough to reimplement in half a day. Proposal: spike it in a branch to confirm Nova version compatibility; if it renders correctly on create/update/detail, vendor the source into our app rather than adding a Composer dependency, and assign an owner. If it fails the compatibility check, we build the field in-house — the scope is a PHP Field class plus a Vue component, and the acceptance criteria are time-only input, 24-hour and 12-hour display, server-side validation, keyboard accessibility, and a clean upgrade path across Nova majors.

Decision and kill criteria: Approve the spike (half a day, no spend). Kill if it fails Nova version compatibility, fails a basic source audit, or requires patching to work at all — in which case build in-house rather than fork. Revisit only if the scheduling surfaces expand beyond internal admin, at which point the question becomes a scheduling data model, not a form field, and this package is out of scope entirely.