Nova Time Field Laravel Package

Product Decisions This Supports

• Feature scoping and roadmapping for internal admin tools. This unlocks a narrow but real class of features inside Laravel Nova: shift planning, appointment slots, operating hours, class/room timetables, simple event start times, and time-of-day logging. Use it to answer "can we ship this admin screen this sprint?" — the answer is usually yes if the requirement is a single time-of-day value and no timezone logic.
• A build-vs-buy call that lands on "buy, but own the exit." MIT license, one small PHP field class, standard Nova field registration. Estimated cost to integrate: hours, not weeks. The buy case collapses if you're on Nova 4/5, need a maintenance SLA, or need timezone-aware scheduling — in those cases the same few hours go into an in-house Nova field you control.
• Dependency classification on the roadmap. Treat as low-cadence and usable with contingency — not abandoned, not dependable. With 61 stars, zero dependents, and a last release in November 2020, it must not become a strategic platform component or sit unguarded on a critical path. Record a fork/replace trigger in the tech-debt register at adoption time.
• Forcing explicit product decisions on time semantics. The package supplies a picker; it does not supply your policy. Adopting it forces the team to answer, in writing: display format (12h vs 24h) vs. stored precision, seconds yes/no, nullable vs. required, wall-clock vs. timezone-bound, and whether date and time are one column or two. These are product decisions that otherwise surface as bugs three weeks post-launch.
• De-risking the Nova upgrade conversation. If a Nova major upgrade is on the roadmap, this package is a named line item in that project's scope. Knowing that up front turns a surprise blocker into a scheduled few hours of vendoring work.
• Deliberately not driving Nova adoption. If the organization hasn't standardized on Nova, this is not a reason to. It is a per-field convenience, evaluated field-by-field, not an ecosystem commitment.
• Sizing what "we need time features" actually means. Use the package to separate the cheap 80% (pick a time of day) from the expensive 20% (ranges, recurrence, timezones, durations, calendar math). That framing usually changes the estimate and sometimes the scope.

When to Consider This Package

• Adopt when all of the following hold: you run Laravel Nova (and are confirmed on a Nova 3-era field API), the need is a straightforward time-only input, engineering can test against your exact Nova version, and the workflow is internal and non-critical.
• Adoption gates before it reaches production:
  • Compare the package's laravel/nova constraint against your Nova major version — Nova 4/5 will either block install at Composer or register-then-render-blank. That's a vendor and port signal, not a dead end.
  • Pin ^1.2. Do not target dev-master on a package with a multi-year release gap.
  • Install on a throwaway branch and read src/Time.php — the README is thin and the source is the real documentation.
  • Smoke-test the full round trip (create → edit → index → detail) and inspect the raw column value, not the formatted output.
  • Verify nullability end-to-end, including whether a cleared picker submits '' rather than null.
  • If the field is used with dependsOn, readonly, or any reactive change-handling feature, test that path explicitly — v1.2's handleChange override is a known deviation from Nova's method signature.
• v1.2 diligence specifically: bugfix-only, but it moved flatpickr initialization to the parent component and carries that temporary handleChange workaround. Re-test existing forms on upgrade even though no breaking changes are declared, and re-check these paths on every future Nova upgrade.
• Look elsewhere when you need: Nova 4/5 compatibility guarantees, predictable release cadence, security patching SLAs, an active troubleshooting community, timezone/range/recurrence semantics, or compliance with a policy against low-activity dependencies.
• Evaluate alternatives first in those cases: Nova's built-in DateTime field configured for time-only display, a small in-house Nova field, or a more actively maintained package. If time features are business-critical, or a Nova upgrade is within two quarters, skip straight to vendoring the PHP field and Vue component.

How to Pitch It (Stakeholders)

Executives: This is a low-cost, MIT-licensed Nova field that saves engineering hours on simple internal time-entry screens — shift planning, appointment slots, operating hours, time logging. Approve it as a tactical dependency for non-critical workflows only. It is not a strategic platform investment: the package is small, has a 2020-era release cadence and an older Nova 3-era front end, and carries a known maintenance contingency. Budget the contingency now — a few hours of vendoring if time-based features become business-critical or the team upgrades Nova — rather than discovering it during an upgrade.

Engineering: The PHP side is a thin Laravel\Nova\Fields\Field subclass that takes minutes to read and a handful of lines to register in a resource. The real surface area is the shipped compiled front end: a pre-Vite, Vue 2 flatpickr bundle in dist/ with no reproducible build path for you, plus a v1.2 handleChange override that deliberately does not match Nova's method signature. Plan accordingly — pin ^1.2, verify Nova version compatibility before writing field code, read the source rather than the README, and add the one round-trip test that asserts the raw column value survives a save. If this lands on anything business-critical or a Nova upgrade is planned, vendor the PHP class and Vue component into nova-components/, rebuild against your own toolchain, and restore a standard handleChange — a few hours of work that removes the single largest ongoing risk. Treat dist/ as the shipped interface, not src/; and remember there is no config surface, so all behavior is configured per-field in the resource.