idf/nova-worldclock-card
A lightweight Laravel Nova card that displays a live world clock, letting you track current times across multiple time zones right from your dashboard. Quick to install and easy to configure, it adds a clean, at-a-glance clock widget to any Nova dashboard.
Architecture fit. Unchanged in shape: idf/nova-worldclock-card remains a Laravel Nova dashboard card — one PHP class extending Laravel\Nova\Card plus a Vue component. Still no models, migrations, routes, service bindings, middleware, or event listeners. The architectural surface area is still correct for a low-risk dependency: it cannot touch the database, cannot alter request lifecycle behavior, and cannot interfere with domain code.
One clarification arrived with 3.4.0: the package maintains its own asset build (laravel-mix + webpack, with @vue/compiler-sfc 3.5.x in the toolchain). That resolves the earlier open question — the card ships a build pipeline rather than expecting the host application to compile its Vue. Our CI stays clean. It also confirms a Vue 3 target, which points squarely at Nova 4/5 and mostly retires the Nova 3 / Vue 2 silent-blank risk.
Integration feasibility. The PHP-side install is still trivial, but feasibility has changed materially at the platform layer. 3.4.0 raises the minimum PHP to 8.4 (from 8.3). For a purely presentational widget, that is a disproportionate constraint: it means the card cannot be adopted unless the host application is already on 8.4+, and it means a widget is now on the critical path of our PHP upgrade calendar. Any environment pinned to 8.2/8.3 is hard-blocked at Composer resolution — which is at least a loud failure, not a silent one.
Two further signals worth weighing:
^3.4 constraint therefore cannot be assumed safe across patch/minor updates. Treat this package's version numbers as advisory and pin exactly.laravel-mix 6.0.49 floating webpack: ^5.60.0 against webpack 5.107.0's removal of lib/SizeFormatHelpers and tightened ProgressPlugin validation. That is a real instance of the failure mode this assessment previously only predicted. Pinning webpack fixes it today; the underlying pattern (unbounded transitive floats in the build chain) will recur.Technical risk.
composer.json constraint on laravel/nova should still be read directly rather than trusted from the README.HttpUriPlugin allowedUris bypass). Correctly triaged by the maintainer: only reachable with experiments.buildHttp enabled, which this package does not use. This is a build-time/dev dependency, not runtime code shipped to the browser. No runtime exposure, no action required beyond standard lockfile hygiene.actions/* bumps to current majors, and an adopted coding standard indicate an actively maintained, forward-tracking package, not an abandoned internal courtesy drop. The prior "de facto maintainers on day one" framing is now too pessimistic. The future-dated release metadata flagged earlier is consistent with the forward-dated toolchain (PHP 8.5, Laravel 13) and reads as environment context rather than an anomaly — confidence penalty withdrawn.Key questions. Is PHP 8.4 a hard composer.json floor or a documented recommendation with a tolerant constraint? Will 3.3.x receive security-only backports for PHP 8.3 environments, and for how long? Is the project adopting semver properly (i.e., should this have been 4.0.0, and will the next breaking change be)? Does the released package include a freshly built dist/, or is the fixed build pipeline only exercised on the maintainer's side — i.e., was any previously published version shipping a stale or broken bundle? Does the card use Intl.DateTimeFormat or a bundled tz library, and what is the transitive JS weight? Is timezone configuration static in PHP or user-editable?
Stack fit. Narrowed. Previously "Laravel 9–11 on Nova 4/5"; now effectively Laravel on PHP 8.4+ with Nova 4/5, with Laravel 13 explicitly on the roadmap. That is a forward-leaning stack, and teams on it are well served. Teams on 8.2/8.3 — still the majority of production estates — are excluded outright and should stop here; there is no reasonable case for accelerating a PHP upgrade to obtain a dashboard clock.
Migration path. Still additive at the application layer: no schema changes, no backfill, no route changes, no config rewrite; rollback remains composer remove plus deleting one array entry. The new caveat is Composer-level: on a PHP 8.3 host, the upgrade from 3.3.x to 3.4.x is a hard resolution failure, so any shared dependency constraint spanning environments of mixed PHP versions will break. Pin the version per-environment rather than relying on a caret range.
Compatibility. Verify four constraints, in this order: (1) PHP 8.4+ on every environment that resolves this package — including CI images and any local Docker/Vagrant parity setup; (2) declared laravel/nova range against our pinned Nova; (3) Vue 3 / Nova 4-5 alignment (strongly implied by @vue/compiler-sfc 3.5.x); (4) confirm the shipped dist/ is current by inspecting the published package contents directly. The host-build question is now largely closed — the package owns its build — but confirm that the released tarball actually contains the fixed bundle rather than requiring a maintainer-side build we cannot reproduce.
Sequencing. (1) Confirm Nova license coverage and version. (2) Confirm PHP 8.4+ across app, CI, and container images — this is now the gating step and should be checked before any engineering time is spent. (3) Read composer.json and the published dist/ directly. (4) Pin the exact version and document the pin rationale (minor releases have carried breakage). (5) Configure the timezone set against actual team distribution. (6) Visual QA in light/dark mode alongside existing cards. (7) Pilot with a small admin group. (8) Record the removal procedure in the runbook.
Maintenance. Ongoing effort remains near-zero while Nova's major and our PHP minor hold — but the maintenance profile has changed. Breaking changes can arrive in minor versions, so the operating discipline is exact version pinning plus a scheduled review on each release rather than a caret-range-and-forget posture. The package is visibly maintained, which lowers the fork-and-own probability; the fork contingency (one card class plus a Vue component) stays cheap and remains the right fallback. Note the package now moves the PHP floor ahead of the broader ecosystem, so its release cadence can outpace our platform cadence — expect periodic "we cannot take this update yet" divergence, which is fine provided we pin.
Support. MIT, GitHub issues only, no SLA, no security disclosure process. The webpack CVE was handled competently and with accurate reachability analysis, which is a positive signal for a maintainer with no formal process. Still acceptable only because the widget is non-critical and non-privileged. It must not become an operational dependency: no on-call surfaces, no SLA dashboards, no alerting.
Scaling. Unchanged and negligible. One card registration, zero database queries, client-side rendering per admin session. Timer-driven re-renders are trivially cheap at any realistic seat count. No scaling work required.
Failure modes.
dist/ in a published release.None carry data-loss, security, or availability impact; the webpack CVE is build-time only and not reachable. Retain the mitigation of gating the card behind a Nova canSee check or environment flag so removal is a config change.
Ramp-up. Still minutes for a Laravel developer familiar with Nova, and slightly easier than assessed previously since asset compilation is the maintainer's problem, not ours. The new non-obvious step is environmental rather than technical: verifying PHP 8.4 parity across application, CI, and developer machines before the first composer require. No new infrastructure, secrets, or network egress.
TPM recommendation. Adopt only if the estate is already on PHP 8.4+ and Nova 4/5, and pin the exact version. The 3.4.0 breaking change converts this from a zero-friction convenience into a package with a platform opinion; for teams on 8.2/8.3 the decision is closed regardless of the widget's merits, and a ~50-line custom card remains strictly better value with full ownership and no version coupling. Where the platform does qualify, the release improves the case: active forward-tracking maintenance, a resolved build pipeline, correct CVE triage, and confirmation of a Vue 3 target. Keep the one-sprint timebox and decide on build-vs-adopt, not on the package in isolation — and record the version pin and its rationale in the runbook, because this project's minor releases are not reliably non-breaking.
How can I help you explore Laravel packages today?