Nova Unit Field Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel Nova custom field package that adds a "unit" input type to Nova resources. It fits only if the platform already standardizes on Laravel + Nova for internal/admin tooling and has domain attributes that are naturally unit-qualified (quantities, measurements, pricing per unit, thresholds). In that context it removes the need to build and maintain a bespoke Nova field. If the estate does not use Nova, or uses Filament/Inertia-based admin surfaces, there is no architectural fit and the package should be deferred. The release note — "Create laravel nova unit field" — describes an initial v1.0.0 scope only; it does not document storage format, conversion behavior, or Nova version support.

Integration feasibility. Superficially low-effort: Composer install, register the field in a Nova resource, and add the corresponding persistence columns. Real feasibility depends on unverified constraints: PHP/Laravel/Nova version compatibility, compiled frontend assets for the Nova field, validation rules, and whether the field stores a compound value or separate value/unit columns. A TPM should treat this as a short spike (1–2 days) rather than a committed integration until the compatibility matrix and storage contract are confirmed.

Technical risk. Moderate for an initial v1.0.0 with a one-line release note. Key risks: coupling to a specific Nova major version (Nova 3/4/5 field APIs and asset pipelines differ); unknown test coverage and maintainer cadence; no documented deprecation or upgrade policy; ambiguous data model that, if compound, complicates sorting, filtering, aggregation, and reporting; and silent inconsistency if units are free-text rather than constrained. Security exposure is low because Nova is admin-gated, but data-quality exposure is material if validation is weak.

Key questions.

• Which Nova, Laravel, and PHP versions are supported, and is there a CI compatibility matrix?
• Does the field persist value and unit separately, as JSON, or as a single string? Is conversion/normalization supported?
• Are unit options enumerated/constrained, and is localization (decimal separators, unit labels) handled?
• Does it support Nova sorting, filtering, and validation rules, and does it expose the value cleanly for API/serialization?
• Who maintains the package, what is the license, and is there test coverage and a release/upgrade policy?

Integration Approach

Stack fit. Valid only for Laravel + Nova estates. Confirm the package's composer.json constraints against the platform's pinned Laravel and Nova versions before any design work. If the team is on a Nova version outside the supported range, stop and evaluate alternatives (native Nova fields, a maintained fork, or a small in-house field).

Migration path. Greenfield resources are straightforward: add typed columns (e.g., decimal for value, constrained string/enum for unit) or a documented JSON column, register the field, and seed the unit option list. For existing resources that capture units as free text, plan a backfill/normalization step before switching the UI, and keep the old column readable until reconciliation is complete. Avoid adopting the field for resources where units are polymorphic across records unless the storage contract supports it.

Compatibility and sequencing.

1. Verify license, maintenance signals, and version constraints; run the package test suite or a smoke test in a disposable app.
2. Build a one-resource proof of concept covering create, edit, validate, sort/filter, and API serialization.
3. Agree a unit taxonomy and storage convention with the data owner; document it.
4. Roll out to a pilot resource, then standardize across similar resources.
5. Pin the version in composer.lock, add an upgrade note to the platform runbook, and re-test on each Nova upgrade.

Operational Impact

Maintenance. A third-party field package adds a small but real dependency to the admin layer. Assign an owner, watch releases, and keep a fork-or-replace option if the maintainer goes dormant. Because it is UI-layer only, removal cost is bounded.

Support. Expect community/single-maintainer support. Internal documentation should cover the unit taxonomy, storage convention, and the exact Nova/PHP versions validated. First-line support can triage data-entry issues; package bugs escalate to the maintainer or fork.

Scaling. Runtime impact is negligible — Nova admin traffic is low-volume and the field does not sit on the hot path. The scaling concern is analytical: separate value/unit columns scale well for aggregation and reporting; compound storage does not. Ensure the chosen schema supports the reporting queries the business will actually run.

Failure modes. Nova major upgrade breaks the field's compiled assets or APIs; inconsistent or free-text units corrupt downstream aggregates; missing validation admits negative or null values; absent sort/filter support degrades admin usability at scale; maintainer abandonment leaves the field unpatched. Mitigate with version pinning, a pre-upgrade regression checklist, constrained unit options, and a documented fallback to a native field.

Ramp-up. Low for Laravel developers already fluent in Nova — hours, not weeks. The TPM cost is mostly governance: defining the unit taxonomy, approving the storage contract, and sequencing the rollout. Budget a short evaluation spike plus documentation time; do not commit to broad adoption until the compatibility and data-model questions are answered.