Nova Opening Hours Field Laravel Package

Technical Evaluation

Architecture fit. This is a single-purpose Laravel Nova form field: an admin-UI widget that binds to a model attribute and persists weekly opening hours — multiple time ranges per day, closed days, full-day availability — as structured JSON. From a program lens it is a commodity admin component with a contained blast radius: no public request path, no queue consumers, no external services, no customer-facing surface, one column per affected model. That containment is why it can be approved quickly and reversed cheaply. The trade-off is that it is hard-coupled to Nova's internal field API and asset-publish pipeline, which are Nova-major-version-sensitive — so it belongs on the admin platform line of the architecture diagram, not on the product dependency list.

Integration feasibility. Integration work itself is small and well-understood: composer require, nova:publish, cache clear, wire the field into a resource, smoke test. The program-level difficulty is sequencing, not engineering. v4.0.0 is a compatibility-only major whose sole change is Nova 5 support, and by implication it drops Nova 4. That means the package cannot be upgraded independently — it is a lockstep rider on a Nova upgrade, and Nova is a paid commercial product whose license, PHP/Laravel constraints, and sibling add-on readiness are the actual cost and schedule drivers. This package is downstream of that decision and should never be the reason for it.

Technical risk. Four risks matter at TPM level. (1) Version-lock coupling — teams on Nova 4 cannot consume v4.0.0, and future fixes will land only on the 5.x line, making 3.0.7 a maintenance dead end the moment we commit. (2) Storage-format ambiguity — release notes say nothing about whether the stored JSON shape, field FQCN, or option API changed between 3.0.7 and 4.0.0. A compatibility-only major suggests no schema change, but we should treat that as a hypothesis to be verified against real records, not a fact. (3) Bus factor — 38 stars, zero dependents, single maintainer, no SLA; acceptable for an admin widget, but the only real contingency is a fork, so the fork must be feasible, which means we must know what to fork. (4) Scope confusion — the package captures hours; it does not evaluate them. No open/closed logic, timezone conversion, holiday overrides, or overnight-span rules. If a stakeholder assumes "Open now" comes free with this, we will discover the gap in QA. That is a separate build, likely layering spatie/opening-hours.

Key questions. Is v4.0.0 strictly Nova 5-only, and what are the exact composer.json constraints on laravel/nova, Laravel, and PHP? Did the field FQCN, option API, or persisted JSON schema change between 3.0.7 and 4.0.0 — and is there an upgrade guide or data migration? Are there open Nova 5 issues in the tracker? Which Nova resources in our estate currently instantiate this field, and what does a sample stored record look like for each? What is the maintainer's release cadence relative to our Nova upgrade calendar? And is our rollback pin (3.0.7 + Nova 4) still installable today?

Integration Approach

Stack fit. Adopt where the admin layer is Laravel Nova 5 and editors need structured recurring weekly hours attached to a model — venues, branches, stores, clinics, service desks. Wrong tool for non-Nova admin stacks (Filament, Livewire, Inertia, Blade), for headless/API-only products, and for any requirement that includes availability computation. The mental model to socialize with stakeholders is data capture, not a scheduling engine.

Migration path. Treat this as a paired upgrade with Nova 5, never standalone. Sequence: (1) inventory every Nova resource instantiating the field and export a representative sample of stored hours JSON per resource; (2) upgrade Nova to 5 first — license, PHP/Laravel, and all other third-party fields confirmed 5.x-ready; (3) validate the core admin boots; (4) move this package from ~3.0.7 to ^4.0 with an explicit pin, not a floating constraint; (5) run nova:publish to rebuild compiled assets and clear caches; (6) regression-pass create/edit/view/detail on each affected resource, explicitly covering closed days, multiple slots per day, split shifts, and overnight spans; (7) diff one post-upgrade record against its pre-upgrade sample to confirm the storage shape is unchanged; (8) promote with a documented rollback pin to 3.0.7 + Nova 4.

Compatibility. Verify the package's PHP and Laravel constraints are a compatible subset of Nova 5's. More importantly, run a Nova 5 readiness inventory across the whole add-on estate — if a sibling field lags, this package should follow that readiness check rather than trigger it, or the upgrade stalls on an unrelated blocker. Also confirm asset-publishing behaviour survived the bump: Nova field packages commonly ship compiled JS that must be re-published after a framework-major change, and stale assets present to editors as a silently broken widget rather than a deploy failure.

Sequencing. The critical path is the Nova upgrade. Model the dependency as: Nova 5 (commercial + technical) → sibling add-on readiness → this field's major bump → asset rebuild → regression → production. Do not merge this package's major into a release branch independently — it will fail install against a Nova 4 lockfile and, worse, can land in a branch where Nova was only partially upgraded, producing an admin break that is slow to diagnose. If Nova 4 remains the target this cycle, pin 3.0.7 and close the ticket; there is no value in partial adoption.

Operational Impact

Maintenance. Steady-state effort is near zero — narrow UI component, no runtime services, no jobs, no public surface. The recurring cost is cadence: each Nova major will likely require a matching package major, so it should be budgeted inside every Nova upgrade cycle rather than discovered as ad hoc work. The highest-value TPM deliverable here is a short internal note filed with the Nova upgrade runbook capturing three durable facts — which resources use the field, the exact stored JSON shape, and the installed field FQCN. That turns a future fork or replacement into a day's work instead of an archaeology project, and it survives staff turnover.

Support. Community-maintained on GitHub: single maintainer, no SLA, small user base, zero dependents. For an internal admin field that is usually tolerable, but it should sit on the dependency risk register with an explicit contingency line — if the project goes dormant, we fork — and with the note that low star count and zero dependents mean community pressure will not force a fix if the maintainer steps away. Escalation paths are internal, not vendor.

Scaling. Negligible on the package side: one JSON column per record, admin-editor traffic only, nothing on the public request path. The scaling conversation that is worth having is downstream — if the storefront or public API later needs "Open now / Opens at 09:00" badges or store-locator filtering, that evaluation runs per request and should be cached per location and invalidated on saved, with the location's timezone stored in its own column and respected explicitly rather than relying on app or worker defaults. Flag this at planning so nobody budgets the package as also delivering the runtime feature.

Failure modes. The dominant failure is a silent post-upgrade break: the field fails to render, assets are stale, the widget loads but saves as a no-op, or stored JSON is misread on display. Because the surface is admin-only, monitoring will not catch it — editors will, usually at the worst moment. Mitigation is a post-deploy checklist item that round-trips an edit in staging plus a canary edit in production. Secondary is dependency deadlock: the whole Nova 5 upgrade stalls because this or a sibling add-on is not ready, which argues for confirming 5.x readiness before committing to an upgrade date. Tertiary is scope drift — teams storing hours assuming evaluation is included, then discovering the "open now" gap late; raise that as a separate ticket up front.

Ramp-up. Effectively nil for engineers — an afternoon including the resource wiring and smoke tests; the real ramp is organizational (getting Nova 5 readiness confirmed and sequenced). Editors need a short walkthrough of the day-by-day control (multiple ranges, closed-day toggle) and, importantly, a stated convention for timezone and overnight spans so the captured data is interpretable downstream. Budget the stakeholder alignment, not the coding.