- What is ostheneo/nova-fields and what does it do?
- It is a Composer package that adds a collection of custom field types to Laravel Nova, so you can enrich your admin panel forms and detail views without rewriting the same field logic in every project. Each field is a standard Nova field class plus a Vue component registered through Nova's documented field API, which means it sits alongside built-in fields in your resource definitions. The package is intentionally lightweight: no service providers to configure beyond Nova's normal booting hook, and no platform-level architecture changes. It is best treated as a set of reusable admin-panel inputs rather than a framework extension.
- How do I install ostheneo/nova-fields in a Laravel Nova application?
- Install it with Composer using composer require ostheneo/nova-fields, then publish and register the field assets the way Nova expects for third-party fields. If the package does not ship a prebuilt dist directory, you will need to run its Mix or Vite build and execute nova:publish before anything renders. Always run composer require --dry-run first to confirm the package resolves against your current Nova major and Laravel constraint, since a 2022-era release will often fail closed on modern versions.
- Does ostheneo/nova-fields support Laravel Nova 4 or Nova 5?
- You should assume it targets Nova 3 (Vue 2, Laravel Mix) until you verify otherwise, because the last release dates to May 2022, before Nova 4 moved to Vue 3 and Vite. Check the composer.json constraints for the Nova major and run a dry-run install to see whether it resolves on your install. If your application is already on Nova 4 or 5, the realistic path is to vendor the field class and Vue component into app/Nova/Fields and port the component rather than depend on the package. If you are genuinely pinned to Nova 3, a constrained dependency can serve as a short-lived interim.
- How do I use these custom fields inside a Nova resource?
- Use them exactly like built-in fields: import the field class and return an instance from your resource's fields() method, typically chained with make() and any options the field exposes. Options are passed through withMeta() and the component name is set on the field class, so registration is the standard Nova flow. The main gotcha is the component name string must match the name registered in Nova.booting(), otherwise you get a blank field with no PHP error to debug.
- Does the package include prebuilt JavaScript assets or do I need to compile them?
- That is one of the first things you must verify before committing to a sprint: check whether the repository ships dist/js/field.js or whether it is source-only. If dist is missing, you have to build the Vue component locally with Mix or Vite and run nova:publish so Nova can load it. Source-only packages are the usual cause of a field that appears registered but renders nothing.
- What does ostheneo/nova-fields store in the database for each field?
- The description does not state the persistence contract, so treat this as an open question until you read the field class and its resolveUsing and fillUsing logic. It may persist a scalar, a JSON string, or a cast object, and each has different consequences for your column type and any migration you might need. The real test is not that the UI renders correctly but that the database column value round-trips cleanly on create, update, and repeat saves.
- Do these fields validate input automatically?
- No. The package does not stress-test nulls, empty arrays, or repeat saves, and it does not validate itself. Every usage in your resource should carry explicit ->rules() and ->nullable() so the field cannot write malformed data silently. Treating these fields as presentation-only and handling validation in your resource is the safest pattern.
- Is ostheneo/nova-fields maintained and safe to use in production?
- The package was last released in May 2022, has a single maintainer, and has no CI or visible audit trail, so there is no upstream patch path or CVE response. Adoption effectively transfers maintenance to your team, which argues for a vendored fork you own rather than an open-ended dependency. Do not let these fields touch money, PII, permissions, or audit paths without your own review, and check that user-supplied HTML is escaped to avoid an inherited stored-XSS vector.
- Should I fork and vendor ostheneo/nova-fields instead of requiring it with Composer?
- For most modern Nova installs, yes. The MIT license lets you lift the field class and Vue component into app/Nova/Fields and own roughly one field type's worth of code, which is usually about a day of engineering to port, namespace, register, and test. Vendoring also keeps the package out of your Composer resolution graph and puts it on your own upgrade checklist when you move Nova majors. Name an owner for the forked copy and keep it in a location your team controls.
- When should I use a Nova built-in field or write my own instead of installing this package?
- Force an inventory of which specific field type maps to a gap Nova's built-ins genuinely cannot fill, because most custom-field requests collapse at that step. If a built-in field covers the use case, use it and skip the dependency entirely. If you do need custom behavior, a small field class plus Vue component written in-house is often lower risk than adopting an unmaintained package. Test the database value, not just the rendered input, before you rely on it in a revenue-adjacent workflow.