- How do I install 64robots/nova-fields in a Laravel Nova application?
- Install it with composer require 64robots/nova-fields, pinning the version rather than floating it, because Nova field packages are coupled to Nova's front-end contract. The package requires no migrations, config files, or service providers of your own; field classes register into Nova's fields() contract via Laravel auto-discovery. After installing, run php artisan nova:publish and clear your caches, then drop the field classes into your resource definitions like any native Nova field.
- Which Laravel Nova versions does 64robots/nova-fields support?
- Support is governed entirely by the laravel/nova constraint declared in the package's own composer.json, so check that constraint against the Nova major you are running before committing. The last release was May 2024 and the package has effectively zero dependents, so verify manually instead of assuming current Nova versions work. Add a verify-nova-fields-against-the-new-Nova-major line item to your Nova upgrade runbook, with a re-evaluation trigger if the package goes a full Nova major without a release.
- What field types does 64robots/nova-fields add beyond Nova's defaults?
- The package ships ready-made inputs such as currency, country, phone, email, URL, and percentage, so you can build admin panels without writing your own Vue field components. Some of these overlap with what Nova core already covers, such as searchable BelongsTo, formatted numbers, and slug-ish inputs, so inventory which fields you actually need first. The package is a convenience layer inside Nova only and is inert outside a licensed Nova installation.
- How do dependent fields work with the Configurable trait in nova-fields?
- The Configurable trait makes a field dependent, meaning it shows or hides based on the value of another field in the same form, so long forms only reveal what is relevant. You declare this inline in your resource's fields() method, per field and per resource, with no global configuration required. Keep it off customer-facing surfaces and treat it purely as admin UX configuration.
- Do nova-fields support validation rules and chaining like native Nova fields?
- Yes, fields chain like native ones using rules(), help(), and nullable(), so validation and testing behave as expected. Even so, pilot one display-only field in a single low-traffic internal resource first and confirm it renders on form, detail, and index views with a clean console and a value that round-trips unchanged. Widen adoption one field at a time after that.
- Is 64robots/nova-fields still maintained?
- The package is MIT-licensed, has a single maintainer, and its last release was May 2024, so the correct posture is that you may end up owning the fork. Name an internal owner who is empowered to patch a Nova field when it lags an upstream Nova release. Because rollback is a one-line revert on one resource, the dependency is cheap to approve as long as someone owns it.
- Will a composer update break my Nova admin panel with nova-fields installed?
- It can, which is why pinning the package version is mandatory rather than hygiene: floating constraints on front-end-coupled field packages turn every composer update into an unreviewed admin-panel change. Nova major drift without a matching package release produces blank fields and console errors silently in production admin. Track the laravel/nova constraint as the hard gate and PHP/Laravel minor drift as a secondary concern.
- Do currency or slug fields in nova-fields transform data on write?
- Write-transforming fields such as currency and number normalization or slug generation change what actually lands in the database, and the failure mode is bad data written with no exception thrown. Identify which adopted fields transform on write and assign an owner for the before-and-after audit of those columns. Do this audit before the fields go anywhere near real data.
- How does the Google Places field work and what are the risks?
- The Google Places field requires a third-party API key, makes outbound calls from the browser, and carries quota and billing exposure, with address data counting as PII. Treat it as a separate go/no-go decision rather than bundling it into the package adoption. If it is not clearly in scope, explicitly exclude it and use a plain text field instead.
- How do I test and roll back nova-fields if something breaks?
- Adopt per field and per resource, starting with one display-only field in a single low-traffic internal resource, then verify it renders correctly on form, detail, and index views with a clean console and an unchanged round-trip value. Rollback is a one-line revert on one resource, which is the property that makes this cheap to approve. There is no database migration and no codebase migration to undo.