- What is marshmallow/prefiller-field and what problem does it solve?
- It is a Laravel Nova field that automatically fills a form input using the value of another field, request data, or a custom default. It targets repetitive admin-form patterns such as slug-from-title, billing-to-shipping address, or SKU-to-label, so you write less per-resource form setup. Because it is a Nova field rather than a general Laravel package, it only applies to Nova admin resources and does nothing in Filament, Livewire, or a custom Inertia/Vue admin.
- Which Laravel and Nova versions does prefiller-field support?
- The realistic target is Laravel 9 or 10 on PHP 8.1+ with Nova 4.x on a Vue 3 front end. The package shipped a single release in August 2023, so verify the composer constraints actually permit your installed Laravel and Nova versions before committing. Nova 3 (Vue 2) and Nova 5 should be treated as unsupported until you prove otherwise in a spike.
- How do I install the Prefiller field in Laravel Nova?
- Install it with composer require marshmallow/prefiller-field, then reference the Prefiller field class inside a Nova resource's fields() method in place of the standard field you would otherwise use. There are no migrations, service provider registrations, queues, or config files to publish. The real onboarding cost is reading the source to understand how it writes into Nova's client-side form state.
- How do I configure the source and target fields for prefilling?
- You declare the source-to-target relationship through the field's fluent API inside your resource's fields() method; consult the README and source for the exact method names, since Nova form-state mutation is not a documented public API. Keep that configuration in one place and wrap the field in an internal class so an upstream breaking change is a one-file fix. Also confirm whether the field only updates the visible form value or influences what gets submitted.
- Does prefiller-field work alongside Nova's built-in dependsOn() reactivity?
- Nova's dependsOn() controls field visibility and reactivity through documented behaviour, while Prefiller writes values into another field's form model, so they are different mechanisms and their interaction is not guaranteed. Test both on the same form in a scratch resource, watching for loops where one field change triggers the other. If conflicts appear, keep dependsOn() for conditional display and apply Prefiller only to fields that are always mounted.
- Will the Prefiller field overwrite values users have already typed?
- Potentially, yes: client-side prefilling writes into a bound field, so a change to the source can clobber text a user has already entered. Guard it deliberately by prefilling only when the target is empty or still untouched, and give users an explicit way to override the suggestion. Treat this as a product-behaviour decision rather than a bug to patch later.
- Is marshmallow/prefiller-field safe to use in production?
- Be cautious. The package has effectively no adoption signal: very few stars, no dependents, a single release in August 2023, no evidence of CI or tests, and one maintainer with no releases in roughly two years. Blast radius is limited because there is no server-side execution path or data at rest, so failure usually means a degraded form rather than corrupted data. Validate every prefilled value server-side and confirm the licence is permissive enough to vendor and fork before you adopt it.
- What happens when I upgrade Laravel Nova to a new major version?
- Expect risk. Prefiller depends on Nova's undocumented client-side form model, which is exactly the layer Nova changes between majors, so an upgrade can leave the field rendering but silently stop prefilling. Sequence adoption as a short spike that includes bumping Nova a minor version to see whether failure is loud or silent. Wrapping the package behind your own field class keeps the escape hatch cheap.
- Does prefiller-field include tests or CI I can rely on?
- There is no evidence of tests or CI in the published package metadata, so do not rely on upstream coverage. Write your own Nova-level or browser tests that assert the target field receives the expected value and that user-entered values are preserved. If you fork the package, add a regression check that fails loudly when prefilling stops working after a Nova bump.
- Does prefiller-field require a Node build step, and what are the alternatives?
- Check whether compiled dist assets ship in the release: if they do, adopting the field adds no JS toolchain to your deploy, and if they do not, you inherit a Node build step. Alternatives include Nova's built-in dependsOn() reactivity, a small custom Nova field, or manual event handling in your own field. On Filament or a bespoke admin panel, use the framework's native reactive form API instead, since this package does not apply there.