Nova Dni Field Laravel Package

Technical Evaluation

Architecture fit. This is a single-purpose Laravel Nova field package — a thin subclass that renders a text input in the Nova admin UI and attaches Spanish identity-document validation (DNI 8 digits + mod-23 check letter, NIE with X/Y/Z prefix, CIF with control character). Architecturally it is a leaf dependency: it touches no models, migrations, queues, or service providers beyond optional auto-discovery, and it stores as a plain string column. That makes it very low blast-radius and easy to reason about. The trade-off is equally clear: the package only earns its place if the estate is already on Laravel Nova and the business has a Spanish/LatAm identity-capture requirement. Outside that combination it is dead weight, and the underlying value — the checksum validation — is roughly 60–120 lines that could be lifted into an application-level Rule object in an afternoon.

Integration feasibility. Mechanically trivial: composer require r64/nova-dni-field, then Dni::make('DNI') in the relevant Nova resource. No asset publishing or migration in the typical case. The real feasibility question is version alignment, not effort. The package's provenance (64 Robots, 8 stars, 0 dependents) suggests it was written against Nova 1.x–3.x on PHP 7.x. Nova 4 moved its front end to Vue 3 and raised the PHP floor; Nova 5 continues that. A field component built for the Vue 2 era is the most likely breakage point — it may install cleanly and fail at render time, which is worse than failing at install. Treat "does it render in our Nova version" as the gating experiment, not "does composer resolve it."

Technical risk. Three distinct risks, ranked:

1. Correctness of the validator. A checksum field that silently accepts invalid documents is worse than no field, because it implies a guarantee it isn't delivering. Must be verified against an authoritative fixture set covering NIE prefixes, CIF control-letter special cases (K/L/M and the digit-vs-letter control variants), leading zeros, and lowercase input. Do not take the implementation on trust.
2. Abandonment. No maintainers, no issue activity, zero dependents means zero community canary. Any breakage surfaces in your estate first.
3. Client/server validation drift. If validation lives only in the Vue component, API writes and imports bypass it entirely. Server-side rule enforcement is non-negotiable for compliance-adjacent data.

Key questions to resolve before committing. Which Nova, Laravel, and PHP versions are supported, and is there a maintained branch? Is validation enforced server-side, client-side, or both? Does the field normalise input (uppercase, strip separators) before persisting, or store raw? Is the license permissive enough for an internal fork? Who owns it if the vendor disappears — us or nobody?

Integration Approach

Stack fit. Assumes Laravel + Nova + MySQL/Postgres, Composer-based dependency management, and an existing admin surface where identity documents are captured. If the team is on Filament, Livewire, or a bespoke admin, this package has no path — port the validation logic and build the input natively. Even within Nova, confirm whether the field is needed for display formatting as well as validation; if only validation matters, a plain Text field plus a custom rule delivers the same outcome with none of the version-coupling risk.

Migration path. Sequence it as an extraction exercise rather than an adoption. First, stand up a throwaway Nova instance at the target framework version and confirm the field renders and validates. If it does, adopt it pinned to an exact version and consider forking into a private VCS so the code is ours regardless of upstream. If it doesn't, the fallback is a first-party DniRule (or the well-maintained Symfony/community validator constraints) wired into a standard Nova Text field — a bounded, low-risk substitution that also removes the Vue 2 dependency permanently. Either outcome takes days, not weeks.

Compatibility and sequencing.

1. Pin the target Nova/Laravel/PHP triple; inspect the package's composer.json constraints and branch aliases against it.
2. Sandbox render test in the target version (this is the go/no-go gate).
3. Build the fixture corpus (valid and invalid DNI/NIE/CIF, malformed, lowercase, empty, null) and assert against both the package rule and the server-side rule.
4. Apply to one low-traffic Nova resource; observe for a sprint.
5. Generalise to all resources capturing identity data, ensuring the same rule guards model-level and API-level writes.

Operational Impact

Maintenance. Effectively unmaintained. Budget for owning it. The mitigations are cheap: exact version pin, private fork, and a regression test against the fixture set that runs in CI so a future framework upgrade fails loudly rather than silently loosening validation. Because the code surface is small, this is a low-cost ownership burden — but it is not zero, and it should not be assumed to be someone else's problem.

Support. No vendor SLA, no community. Escalation path is reading the source, which is feasible given its size. Internalise this in the runbook: one named owner, one documented fork location.

Scaling. Negligible. A form field with a regex and a modulo operation imposes no meaningful load at any realistic admin-panel volume; no database, cache, or queue implications. The scaling concern is organisational, not technical — every additional resource that adopts the field increases the surface that breaks on the next Nova upgrade.

Failure modes. (a) Checksum bug admits invalid documents into records that downstream compliance or invoicing systems assume are clean — highest-severity, lowest-visibility. (b) Component fails to render after a Nova upgrade, breaking the edit form for that resource only; users see a blank or broken input. (c) Client-only validation is bypassed by API writes, imports, or seeders. (d) Asset build incompatibility under Vite/Nova 4+ manifests as a build failure or a silently unregistered component. Each maps to a cheap guard: fixture tests for (a), sandbox upgrade testing for (b) and (d), server-side rule duplication for (c).

Ramp-up. Hours for any Laravel developer. The package is small enough to read end-to-end, and the Spanish ID algorithms are well documented. The genuine ramp-up cost is domain knowledge — knowing DNI from NIE from CIF and understanding the control-character rules well enough to write the fixtures — which is a one-time investment the team needs regardless of whether it adopts this package or replaces it.

Recommendation. Treat it as a candidate for extraction rather than a dependency. The opportunity signal is real — Spanish identity validation is a recurring need with thin tooling — but the package's age, isolation, and version coupling mean the correct move is to verify it, then own it, whether as a fork or as a first-party rule.