Nova Worldclock Card Laravel Package

Product Decisions This Supports

• Operational visibility for distributed teams, inside the tool operators already use. The card renders a configurable list of cities/time zones as live-updating clocks (12/24-hour) on any Nova dashboard. It supports "follow-the-sun" workflows — support handoffs, on-call rotations, regional office hours, release windows — without adding a new internal page, a bookmark, or a third-party site to anyone's routine.
• Build vs buy for non-differentiating internal UI. The scope is deliberately tiny: a list of time zones becomes a clock. Building it is cheap; owning it is not. This is a clear "consume" call — a maintained upstream removes bespoke maintenance from a feature that produces zero competitive differentiation.
• Roadmap sequencing for platform upgrades. Release 3.4.0 raises the runtime floor to PHP 8.4, adds Laravel 13 groundwork and PHP 8.5 to CI, and pins webpack to fix a genuinely broken asset build. That makes the card a line item in the PHP 8.4 migration plan and a forward-compatibility signal when scoping Laravel 13 — not a blocker.
• Incident and release coordination. Anyone in Nova needing a shared answer to "what time is it for the on-call engineer / the EU office / the reviewer" gets it without context-switching out of the admin panel.
• Explicitly not an input for scheduling logic. This is a display widget. Timezone conversion, DST arithmetic, availability search, overlap finding, and timezone-aware notifications belong in application code via Carbon and the tz database. The presence of this card must not be mistaken for a scheduling capability or a commitment to one.
• Deprecation/removal is a legitimate outcome. If the card is deployed but rendered on no dashboard, composer remove deletes the PHP 8.4 constraint at zero feature cost. The usage audit is the decision gate, and it comes before any engineering work.

When to Consider This Package

Adopt when:

• You already run Laravel Nova. Outside Nova this package has no value whatsoever — it is a dashboard card, nothing more.
• Your team spans multiple time zones and operators routinely need a shared clock reference in the admin panel: support desks, incident response, global release management.
• You want near-zero integration cost: composer require, register the card in a Nova service provider, publish config, list your time zones. Hours, not a project.
• You can satisfy PHP ≥ 8.4 in the Nova host, or can sequence this behind the platform upgrade.
• You accept a small upstream (single maintainer organisation, MIT, no commercial support tier) for a low-blast-radius cosmetic widget. The 8-star / 0-dependent profile is a weak external signal; established-organisation provenance is what makes it acceptable for admin chrome.

Look elsewhere or defer when:

• You are on PHP 8.3 or older. 3.4.0 is a hard break on the runtime floor. Pinning 3.3.1 keeps you working, but off the maintained line.
• You are not on Nova, or have deliberately kept the dashboard minimal — a card adds surface area for marginal value.
• You need more than a clock: overlap finding, availability search, timezone-aware notifications. That is application logic, not a card.
• You compile Nova card assets yourself and cannot tolerate build-toolchain churn. Nuance: 3.4.0 fixes real breakage (laravel-mix 6.0.49 floats webpack: ^5.60.0; webpack 5.107.0 removed lib/SizeFormatHelpers), so this release improves the situation — but it confirms laravel-mix/webpack is a slowly decaying moving part.
• You require a formal security-review trail for admin-panel dependencies. For the record, the bundled webpack CVE (CVE-2025-68157) is not reachable here — it requires experiments.buildHttp, which is unused. Log as triaged; do not open a remediation stream.
• The card is not rendered on any dashboard. Removal beats upgrading.

Verify before scheduling: which Nova majors 3.4.0 actually validates against (check composer.lock, not the changelog's forward-looking Laravel 13 language), and whether the published artifact ships pre-built assets or requires consumers to compile. That second answer decides whether the webpack pin is your problem at all.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost Nova dashboard card that shows the current time across our offices and on-call regions, so operators stop context-switching to external sites during incidents and handoffs. No licence negotiation, no data leaving our systems, no new infrastructure, no persistent storage, no background work. The 3.4.0 release is maintenance-grade: it keeps the package aligned with our platform roadmap, fixes a broken asset build, and removes a build-toolchain failure mode. Steady-state cost of ownership is close to zero; the only real gating item is a platform prerequisite, not the card itself.

To engineering: 3.4.0 is breaking only in its PHP floor — 8.4 minimum, up from 8.3. If the Nova host already runs 8.4, this is a routine composer update; if not, the PHP upgrade is the work item and the card is a passenger. The release adds Laravel 13 groundwork and PHP 8.5 in CI — exactly the forward-compatibility signal we want from a dependency we intend to carry through the next major upgrade. The webpack pin resolves a genuine asset-compilation failure caused by laravel-mix floating webpack: ^5.60.0; the webpack bump addresses CVE-2025-68157, which is not exploitable here because experiments.buildHttp is not enabled. Coding-standard 1.0 and CI action bumps are housekeeping. Residual risk is a silent visual regression — a Nova upgrade changing card mounting or asset loading and producing a blank card with no error — so manual dashboard QA (rendering, timezone correctness, light/dark theme) is a required sign-off, not a nice-to-have.

Recommendation: Adopt or upgrade contingent on the PHP 8.4 floor being met in the Nova environment, with the Nova support matrix confirmed first. Sequence the PHP runtime change and the package bump as separate change sets so any resolution failure is attributable to PHP, not to the card. If 8.4 slips, pin to 3.3.1 and revisit at the next platform window. If the card turns out to be unused, remove it — that eliminates the constraint entirely and is the cheaper outcome.