Nova Boolean Datetime Field Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova custom field — a thin PHP class extending Laravel\Nova\Fields\Field paired with Vue components for the index, detail, and form views. It composes two native Nova concepts (Boolean toggle + DateTime picker) into a single control, which maps to a recurring admin UX pattern: "enable flag + timestamp" (publish-at, expires-at, verified-at, feature-toggle-with-window). Architecturally it is a presentation-layer plugin with no backend service, queue, or storage of its own — it depends entirely on how the consuming model persists the boolean and datetime (one compound column or two discrete columns), which must be confirmed before schema design.

Integration feasibility. Low code footprint. Integration is composer require pragmarx/nova-boolean-datetime-field, then referencing the field class in the target Nova resource. The real feasibility gate is Nova version compatibility: Nova 3 and earlier shipped Vue 2 with a Laravel Mix/webpack asset pipeline, while Nova 4 moved to Vue 3 + Vite. A field compiled against the older toolchain will not render correctly in Nova 4. That must be validated before any commitment.

Technical risk. High, concentrated in lifecycle rather than code quality:

• Version coupling — custom fields are tightly bound to Nova's internal asset pipeline and Field API; Nova majors are the primary break vector.
• Low signal — 21 stars and 0 dependents means effectively no production validation and no community backstop.
• Bus factor — single-maintainer package; MIT license is the mitigation, since a fork is always available.
• Data-model ambiguity — unclear whether the field resolves to one persisted value or delegates to two model attributes; this drives migration effort and validation behavior.
• Edge cases — toggle-off semantics (does it null the datetime or retain it?), timezone handling on write, and null/empty states.

Key questions.

1. Which Nova versions are supported, and is the asset build Vue 2 or Vue 3?
2. Does it persist one column or read/write two discrete attributes?
3. Timezone behavior — stored as UTC, app timezone, or user timezone?
4. Is there a test suite, and what is the last commit date vs. current Nova release?
5. Does it support nullable, required, and validation rules on both the boolean and the datetime halves?

Integration Approach

Stack fit. Fits any Laravel application already running commercial Nova. If the organization does not license Nova, this package is irrelevant. It should be treated as a Nova-only UI dependency, not a general Laravel utility.

Compatibility. Pin Nova to a known version and verify the package's composer.json constraint against it before installing. Run the integration exclusively on a staging environment that mirrors the production Nova version, since this class of package fails visibly (blank or broken field) rather than silently.

Migration path. Because the package is a UI wrapper, schema decisions are ours, not the package's:

• Add the required column(s) — a boolean and a datetime, or a single compound column — via a standard Laravel migration.
• Backfill existing data before exposing the field in the UI.
• Roll out to a non-critical resource first, validate reads/writes, then promote to business-critical resources.

Sequencing.

1. Confirm Nova version and asset pipeline compatibility.
2. Install in a feature branch; php artisan nova:publish and verify compiled assets load.
3. Wire into a low-risk model; exercise create, update, toggle-off, and null paths in all three views.
4. Validate timezone round-trip (write → DB → read).
5. Promote to the target resource; document the field usage for other developers.
6. Rollback plan: replace with two native Nova fields (Boolean + DateTime, optionally using dependsOn/conditional display). This achieves ~80% of the UX with zero third-party risk and should be evaluated as the default before adopting the package.

Decision framing (build vs. buy vs. compose). Given 0 dependents and 21 stars, the rational default is composition using native Nova fields. Adopt the package only where the combined toggle-timestamp control delivers materially better operator UX and the team accepts the upgrade-risk overhead.

Operational Impact

Maintenance. Low ongoing cost in normal operation, but with an upgrade cliff at each Nova major. Budget for triage at every Nova release; keep a fork-ready stance given MIT licensing. Assign a named internal owner — there is no vendor support and minimal community surface.

Support. Self-supported. Issue response on GitHub is best-effort and should not be planned around. Internal documentation of the field's behavior (especially toggle-off and timezone semantics) is more valuable than upstream docs.

Scaling. Negligible runtime footprint — it is a front-end field, not a query or job. It scales exactly as Nova scales. The only scaling-relevant concern is asset build compatibility across environments; ensure the published assets are committed or built deterministically in CI.

Failure modes.

• Nova upgrade breaks the Vue component → field renders blank or throws a console error; form submissions may silently omit the value.
• Timezone mismatch → timestamps written offset by the app/user timezone delta.
• Toggle-off does not clear the datetime → stale timestamps persist and are acted on downstream (e.g., scheduling, expiry jobs).
• Asset publish collision with other Nova packages.
• Validation gaps on the datetime half when the boolean is enabled.

Each of these should have an explicit test case in the integration checklist and a documented operational workaround.

Ramp-up. A few hours for any developer already familiar with Nova custom fields; near-zero for end users, since the control is self-explanatory. The real ramp-up cost is institutional knowledge about Nova's asset pipeline for whoever owns the next upgrade.