mimosu/nova-split-date-input
A Laravel Nova field that splits date entry into separate day, month, and year inputs, making date selection clearer and less error-prone for users. Drop-in replacement for the default date field with a simple, focused interface.
Architecture fit. mimosu/nova-split-date-input is a single-purpose Laravel Nova form field that renders one date column as three separate day/month/year inputs. Architecturally it is a thin presentation-layer extension: it implements Nova's Field contract, ships a compiled Vue component (dist/js/field.js), and persists a single scalar date value. It adds no service provider logic, no migrations, no queues, and no external service dependencies. For a TPM this is the lowest-risk category of package: it touches the admin surface only and never enters the request path of the customer-facing application.
Integration feasibility. Installation is the standard two-step Nova pattern — composer require mimosu/nova-split-date-input followed by field instantiation in a Nova::resources() field method. Because the field maps to an existing date/datetime column, adoption is per-field and reversible: swapping back to Date::make() requires no schema change. The realistic effort is hours, not days, contingent on a Nova version check (see risk below).
Technical risk. The dominant risk is Nova major-version coupling. Custom fields subclass Nova internals and depend on the FormField/DetailField/IndexField mixin contracts, which Nova has historically broken across majors. v1.0.0's release note is only a link to the commit history — there is no compatibility matrix, no changelog prose, no breaking-change disclosure, and no test or CI evidence. That absence is itself a governance signal. Secondary risks: single-maintainer bus factor, committed build artifacts that may drift from source, and validation semantics (three inputs bound to one column can bypass date_format rules if the field does not compose them correctly before submit).
Key questions.
composer.json (laravel/nova constraint), and has it been exercised against the version we run?dist artifact reproducible from the tagged source, and is there a build script?->rules(), ->nullable(), and timezone/display-format configuration?Stack fit. Native fit for any Laravel + Nova application on PHP 8.x. It is Nova-only by definition — it offers nothing for Blade, Filament, or API surfaces, so scope its use to admin UX where a split entry genuinely helps (date of birth, document expiry, historical records) rather than applying it uniformly to every date field.
Migration path. No data migration. Existing rows are already valid dates in the same column; the change is cosmetic at the form layer. Rollback is a one-line field swap. This makes it safe to pilot on a single low-traffic resource before wider rollout.
Compatibility. Verify in this order: (1) laravel/nova constraint in the package's composer.json versus our installed Nova version; (2) Laravel and PHP version constraints; (3) presence of dist/js/field.js so nova:publish or vendor asset resolution does not require a Node toolchain on the deploy box. If the constraint is loose (e.g. *), treat declared support as unverified and test explicitly.
Sequencing. Pin the exact tag in composer.json. Install and run php artisan nova:publish in a branch environment. Exercise create, edit, detail, and index views on one resource, plus validation edge cases (null, leap day, out-of-range values). Confirm the persisted value round-trips identically through the API and any reports that read the column. Only then promote to staging and roll out resource by resource. Record the pinned version and the tested Nova version in the internal package register at the same time.
Maintenance. Near-zero routine cost — no scheduled jobs, no config to tune, no database footprint. The real cost is upgrade coupling: every Nova major upgrade requires re-validating this field, and because the package is a solo-maintainer project with an opaque changelog, we should assume we may need to fork and patch the Vue component ourselves. Budget a small contingency for that rather than expecting upstream turnaround.
Support. No vendor SLA. Support is the GitHub issue tracker plus our own reading of the source, which is small enough to audit in an afternoon — do that audit before adoption rather than after. Assign an internal owner so the "who understands this field" question has an answer.
Scaling. Effectively unlimited; the field is client-side rendering over a single column and adds no queries, no payload of consequence, and no per-request overhead. It will not be a scaling consideration at any realistic admin concurrency.
Failure modes. (1) Nova version bump silently breaks the field's rendering or submit binding — mitigate with a smoke test in the Nova upgrade checklist. (2) Partial or malformed input reaching the database because browser-side validation is the only guard — mitigate with server-side ->rules(['date']) on the field. (3) Asset resolution failure after deploy, leaving a blank or unstyled input — mitigate by verifying dist presence in CI, not by compiling on the server. (4) Abandonment upstream; the fallback is a fork, which is cheap given the surface area. (5) Index/detail column rendering diverging from form rendering — verify all three views during the pilot.
Ramp-up. Minimal. A Nova-experienced developer is productive in under an hour; the field's public API is one constructor call plus standard Nova modifiers. Document the field in the team's Nova component catalogue with the pinned version, the tested Nova version, and the fork procedure, so the knowledge is not held by the person who introduced it.
How can I help you explore Laravel packages today?