Nova Date Time Laravel Package

Technical Evaluation

Architecture fit. This is not a general Laravel package — it is a Nova field extension. It contributes a PHP field class extending Laravel\Nova\Fields\Field plus a compiled Vue component registered through Nova::booting(...) and Nova's asset pipeline (Nova::script() / Nova::style()). That means it has zero utility outside Laravel Nova, and Nova is a commercial, closed-source product with its own release cadence and per-site licensing. The architectural dependency chain is therefore: our app → Laravel → Nova (paid, versioned) → this package (unmaintained). We are three links deep on a 5-star, 0-dependent artifact.

Integration feasibility. Mechanically simple — composer require plus a field class in a Nova resource. The real feasibility question is version alignment. Last release was 2020-09-28, which places it in the Nova 3.x era. Nova 4 (2022) was a ground-up rebuild — Inertia.js, Tailwind 3, Vue 3 — and changed the Nova.booting signature and the field-component contract. Packages written for Nova 1–3 generally do not load on Nova 4+ without a rewrite. Assume broken on current Nova until a spike proves otherwise.

Technical risk.

• Compatibility risk (high): Vue 2 → Vue 3 and the Nova 4 component API change likely make the JS bundle non-functional. Failure is silent — the field renders blank or read-only.
• Maintenance risk (high): single author, no releases in 4+ years, no visible CI, no security policy, 0 dependents. Effectively no upstream.
• Value risk (medium): Nova has shipped native DateTime, Date, and Time fields since 2.x/3.x. The differentiator was picker UX (range selection, seconds, min/max, week start, locale) — a narrowing gap with each Nova release.
• Data-integrity risk (medium): third-party pickers frequently handle timezone/local-time conversion their own way. If the component writes local time into a UTC column, we get silent offset drift that surfaces later in reporting.
• Supply-chain risk (low): small footprint, MIT, no transitive runtime dependencies of note — but an old bundled picker library will trip SCA scanners on CVEs.

Key questions.

1. Which Nova major version are we on today, and what is the committed upgrade horizon to Nova 5?
2. What specific capability does native DateTime lack for us — seconds, ranges, timezone display, min/max, locale/week-start? Can we get there with ->withMeta() on the native field?
3. Does the field store UTC or local time, and does it round-trip correctly through our casts?
4. Is this on a revenue-critical admin path or internal tooling? (Determines blast radius.)
5. If we fork, who owns it, and do we have a Vue-capable maintainer for Nova upgrade cycles?
6. Is Nova itself approved spend in our stack, or is this package pulling in a license we haven't budgeted?

Integration Approach

Stack fit. Zero value without Nova; marginal cost near zero if Nova is already licensed. Treat the adoption decision as "Nova field UX decision," not "package decision."

Compatibility.

Migration path. Do not install directly. Recommended path:

1. Gap analysis — enumerate picker requirements against native Nova fields. This will likely resolve 60–80% of the perceived need.
2. Spike — install in a throwaway Nova app matching our version, confirm whether the component even boots. Timebox to half a day.
3. Decide — (a) use native fields with withMeta, (b) vendor the MIT-licensed Vue SFC and PHP class into our own first-party Nova asset bundle and rebuild against current Vue, or (c) build a thin custom field from scratch (~2–3 dev-days).
4. If vendoring — add it to our own repo, not vendor/, so composer update cannot silently drop it. Add a smoke test asserting the field renders and persists.

Sequencing. Gap analysis and the compatibility spike gate everything else and should run in parallel — the spike is cheap insurance against a long gap-analysis cycle on a feature we can't actually ship. Only after both pass does a build/fork estimate make sense.

Operational Impact

Maintenance. Treat as abandoned upstream. If adopted, we own it fully: fork, vendor, and budget roughly 1–2 dev-days per Nova upgrade cycle (Nova ships majors roughly every 18–24 months). Without adoption, ongoing cost is zero.

Support. None. No maintainer responsiveness assumed, no security disclosure channel, no backport path. Internal escalation must terminate at our own team.

Scaling. Negligible. It's a form-control component on admin screens — no runtime hot path, no query impact, no concurrency concerns. Risk is correctness, not throughput.

Failure modes (ranked by severity):

1. Silent data loss — component fails to register post-upgrade, field renders empty, user saves and nulls out existing timestamps. Mitigate with a render smoke test and a ->rules('required') guard on critical fields.
2. Timezone drift — picker serializes local time into a UTC column; reports go subtly wrong weeks later.
3. Asset collision — duplicate Vue component registration names break unrelated Nova fields on the same page.
4. SCA noise — stale bundled JS dependencies generate vulnerability findings with no upstream fix, forcing an internal patch or a risk exception.

Ramp-up. Low to read (~1 hour: one PHP class, one Vue SFC), moderate to safely own — Nova's internals are closed-source, so debugging a broken field means reverse-engineering undocumented contracts. Any fork should be accompanied by a short internal README covering the Nova version it targets and the upgrade checklist.

Bottom line. Score 0.285 with opportunity 35.71 reads correctly: a real but modest UX gap served by a weak, unmaintained vehicle. Do not adopt as a dependency. Validate the gap against native Nova fields first; if it's real, vendor the MIT code or build a ~3-day internal field so we own the Nova-version contract.