Dynamic Fields Laravel Package

Technical Evaluation

Architecture fit This is a Laravel Nova field package, which places it in a narrow architectural slot: it only has value if Nova is already the admin layer. Nova fields extend Laravel\Nova\Fields\Field, ship a compiled Vue component, and are registered through NovaServiceProvider::fields(). The integration surface is small and conventional, which is the package's main technical strength — there is no service provider gymnastics, no database schema ownership, and no runtime dependency beyond Nova itself. The architectural risk is inverted: the package doesn't impose a design, but it also can't be reused outside Nova, so any evaluation is really an evaluation of Nova field extensions as a category.

Integration feasibility Mechanically straightforward: Composer require, optional asset publishing, register the field class in one resource, rebuild Nova assets. A competent Laravel developer should complete a spike in under a day. The feasibility question is not "can we install it" but "does its conditional-display semantics match our form requirements" — dynamic field behavior is easy to demo and hard to get right across create/update/detail views, inline relationships, and ActionModal contexts.

Technical risk The dominant risk is stewardship, not code. Two stars and zero dependents means effectively no production signal, no community bug surface, and no downstream pressure to fix breakage. A single-maintainer Nova field package is structurally fragile because Nova majors change the field/Vue contract and proprietary Nova releases are not something the maintainer can be pinned to. Secondary risks:

• License ambiguity — confirm a LICENSE file exists and is permissive; absent licensing is a procurement blocker regardless of code quality.
• Nova major version coupling — Nova 4 (Vue 2/Inertia) vs Nova 5 (Vue 3) asset pipelines are incompatible; the compiled JS almost certainly targets one.
• Native overlap — Nova ships dependsOn, hideWhenCreating/showWhenCreating, and conditional visibility helpers. A meaningful share of "dynamic fields" use cases may be covered natively, which would make the dependency net-negative.
• Client-side-only logic — if visibility is enforced only in Vue, hidden fields still post; validation and authorization must be enforced server-side independently.

Key questions

1. Which Nova major (and which exact minor) does the compiled asset target, and is that our pinned version?
2. What does "dynamic" mean here — conditional visibility, conditional options, dependency-driven value mutation, or server-side computed fields?
3. Is the behavior enforce-able in rules()/authorize on the server, or is it presentation-only?
4. Is there a LICENSE, a tagged release, and any CI? Are there open issues with no response?
5. Can we meet the requirement with Nova's native dependsOn plus a small custom field, removing the third-party dependency entirely?

Integration Approach

Stack fit Requires Laravel + Nova (paid license, per-site cost) + a Nova-compatible Vue toolchain. If our admin stack is Filament, Livewire, or hand-rolled Blade, this package is a non-starter and should be closed out immediately rather than re-evaluated.

Migration path There is no migration path in the conventional sense — no data model, no persisted state, no backfill. Adoption is a code-level addition to one resource. That cuts both ways: low switching cost in, low switching cost out, which supports a time-boxed pilot rather than a formal adoption decision.

Compatibility Pin explicitly. Verify composer.json constraints for laravel/nova, php, and illuminate/*; verify the compiled asset works with our Nova build (asset publishing, nova:publish, Vite vs Mix). Treat any unpinned nova constraint as a red flag and test against the exact minor we run.

Sequencing

1. Two-to-three day spike: install in a sandbox, reproduce our hardest form requirement, confirm server-side validation behavior.
2. Native-first check: attempt the same requirement with Nova's dependsOn + a 100-line custom field.
3. If the package wins, vendor it (VCS or path repository) and wrap it in an internal field class so resources never reference the vendor namespace directly.
4. Single-resource pilot in production behind a feature flag; instrument for form-submission errors.
5. Expand only after one clean Nova upgrade cycle, or explicitly accept fork ownership up front.

Operational Impact

Maintenance Assume ownership at adoption. With one maintainer and no dependents, the realistic steady state is "we fork it on the first break." Budget a small but permanent maintenance line: annual Nova upgrade review, asset rebuild, dependency bumps. Vendor the code into our repository (or a private Composer VCS entry) on day one — do not rely on Packagist availability for a package with this adoption profile.

Support No SLA, no vendor, no community. Support cost is borne entirely internally; the actual cost driver is the developer who reverse-engineers the Vue component when it breaks, not the acquisition. Ramp-up for a Nova-experienced team is low (hours); for a team without Nova field authoring experience, add a day.

Scaling Negligible performance footprint. Conditional logic is client-side per form render; there is no query impact, no queue usage, no cache surface. Scale risk is organizational rather than technical: every additional resource using the field increases the blast radius of a Nova upgrade without increasing our leverage over the dependency.

Failure modes

• Silent no-op — assets not published or a Vue version mismatch renders a plain field with no error; QA may pass while the feature is inert.
• Server-side bypass — visibility enforced only in the browser; requests submitting hidden fields are accepted. This is a data-integrity and authorization failure mode, not a cosmetic one.
• Nova upgrade break — highest-probability failure; the field stops rendering or throws on the resource page after a Nova bump.
• Abandonment — repository goes dormant; no security patching path.
• Constraint resolution failure — Composer resolves against an unpinned Nova range during an unrelated composer update, breaking admin forms with no code change on our side.

Recommendation Do not adopt as a strategic dependency at 2 stars and zero dependents. Run the native-first spike; if the package's specific behavior is genuinely differentiating, vendor and fork it with an internal wrapper and an explicit owner. Otherwise, implement the narrow slice we need as a first-party Nova field.