- How do I install pavloniym/nova-options-selector?
- Install it with Composer by running composer require pavloniym/nova-options-selector in the root of your Laravel application. No config publishing or asset compilation step is expected, since the package is a Nova field component registered through its own field service provider. After installing, the field class becomes available to any Nova resource in your application.
- Which Laravel and Nova versions does this package support?
- The package targets Laravel Nova 4, and the current 1.1.2 patch is explicitly calibrated to Nova 4.34.3, with Laravel 10/11 and PHP 8.1+ as the practical stack baseline. Because Nova is a paid product and is not distributed via Packagist, check the composer.json constraint in the repository to confirm exactly how the Nova dependency is expressed. If your application is pinned below Nova 4.34.3, validate the field markup against your Nova version before adopting the latest tag.
- How do I add the options selector field to a Nova resource?
- Use the package's field class in place of Nova's built-in Select::make() inside your resource's fields() method, then pass your predefined option list the same way you would with a normal select field. The field then renders inside the Nova resource form and persists its value to the attribute you name. Start with a single low-traffic resource so you can confirm the rendered output before rolling it out elsewhere.
- Does this package require migrations or database schema changes?
- No. The field is a presentation-layer extension that stores its value in the same column format as a standard Nova Select, so no new tables, columns, or migrations are involved. Installation and adoption are measured in hours for a first resource and minutes for each additional one. You only need an existing column capable of holding the select value, or a JSON-capable column if you are storing multiple selections.
- Is it a drop-in replacement for Nova's built-in Select field?
- It is intended as a drop-in for Nova Select: you swap Select::make() for the package's field class without changing your schema. However, verify field parity yourself, particularly whether the class subclasses Nova's Select and inherits methods like options(), searchable(), displayUsingLabels(), nullable(), and rules(), or reimplements them. If it extends Select, existing records read unchanged; if it reimplements, test a round-trip read and write on a seeded record before replacing any field backed by production data.
- Can the field store multiple selected options as an array?
- The package is described as a multiple options selector and, like a multi-select Nova field, it should persist an array of values, typically JSON-encoded in a single column. Confirm the exact storage shape empirically on a scratch resource, since the column format must match whatever you currently store for that attribute. Never assume parity with an existing field's data format on a resource that already holds production values.
- Does this package support Nova 5?
- Nova 5 support is not stated in the current release information; version 1.1.2 is explicitly tuned to Nova 4.34.3. Because the field depends on Nova's internal CSS class names rather than a stable public contract, Nova 5 compatibility cannot be assumed. Ask the maintainer directly whether Nova 5 is supported or on the roadmap before upgrading your Nova installation.
- Will upgrading Nova break this field's styling or behavior?
- Possibly, yes. The 1.1.2 release note says it fixed styles and classes for Nova v4.34.3, which confirms the package reaches into Nova's internal CSS class names rather than relying on a stable public API. Every Nova patch release is therefore a potential styling or UX regression that cannot be fixed upstream, because Nova is a closed-distribution product. Budget a recurring item in your Nova upgrade checklist to re-test this field visually across Chrome, Safari, and Firefox.
- What happens if the maintainer abandons this package?
- The project is a single-maintainer package with no visible support commitment, so abandonment is a realistic scenario to plan for. The upside is that the codebase is small, essentially a few Vue components plus a service provider, so forking and self-vendoring is cheap. Confirm the license permits forking before you adopt it, and consider recording the Nova-to-package version pairing in your repository README so a fork can be rebuilt later.
- How should I test and roll out this field in production?
- Spike on a non-production Nova instance first: install the package, render the field, and exercise the search, nullable, and validation paths, then do visual QA on the exact Nova version you run. Pin both Nova and the package together in composer.lock, since the coupling is bilateral. Adopt per resource, starting with the lowest-traffic admin screen, and remember the blast radius is limited to the admin panel, so a broken style produces an ugly field rather than corrupted data.