- How do I install wamadev/nova-parental-field in a Laravel Nova app?
- Install it with Composer using composer require wamadev/nova-parental-field, and Laravel package auto-discovery should register the service provider without manual wiring. Because the only tagged release is v0.0.0, pin the exact version and commit your composer.lock so installs are reproducible. Verify the Packagist vendor, repository provenance, and that no post-install scripts run before adding it to a real application. Then reference the field class inside the Nova resource where you want the parent selector.
- Which Laravel, PHP, and Nova versions does nova-parental-field support?
- The v0.0.0 release ships with an empty release body, so there are no documented PHP or illuminate/* version bounds to rely on. Inspect the package composer.json for explicit Laravel and Nova constraints rather than assuming support for your pinned versions. Install it into a throwaway Laravel skeleton on your exact versions, run composer why-not, and confirm the Nova major version matches before adopting. Treat any requirement for a Laravel or Nova minor bump as a platform upgrade, not a package install.
- What does the Parental field actually do in a Nova resource?
- It provides a select element in Nova for choosing the child type as part of managing parental relationships between resources. It is intended to let you select and display a parent record directly in Nova forms and indexes with minimal setup. The goal is to avoid hand-rolling a custom Nova field just to wire up the parent side of a relationship. Confirm against your own schema whether the field maps to a foreign key column or only handles the selection and display layer.
- Is it safe to use nova-parental-field v0.0.0 in production?
- At 0.0.x, semver permits breaking changes in any patch release, so an upstream update can change behavior without a major version. The safer pattern is to define your own narrow interface over the field's public API, ship it behind a config flag, and canary it in one low-traffic resource before broad use. That way rollback is a deploy-time toggle and an upstream break is a one-file change. Without release notes or a changelog, you own the upgrade verification work yourself.
- How do I configure the nova-parental-field field?
- There is no documented configuration surface at v0.0.0, so read the source to see which methods the field exposes and whether any config file is publishable. The package is presented as minimal-setup, which suggests most behavior comes from how you declare the field in your Nova resource rather than from published config keys. Anything you can publish should be reversible, and any migrations or stubs should be inspected before running them. Record the exact options you use so upgrades can be diffed against them.
- Does nova-parental-field have tests or CI?
- No test badge, coverage report, or CI configuration is referenced for the project, so test signal is unknown. That does not mean the code is broken, but it does mean you cannot lean on upstream tests as a compatibility guarantee. Write your own smoke tests that instantiate the field, resolve the parent options, and render the index and form views. Run those tests on every dependency update, since a 0.0.x bump is not a stability promise.
- How does the field behave when a parent record is missing or the select is empty?
- Failure-path behavior is not documented, so exercise it explicitly during your evaluation spike. Test an empty option list, a soft-deleted or missing parent record, and a null foreign key on both the form and index views. Check how the field renders when the parent relationship is not loaded, since lazy-loading assumptions are a common source of N+1 queries in Nova indexes. Capture the results in your wrapper tests so regressions surface before users see them.
- What are the alternatives to using nova-parental-field?
- Nova's built-in BelongsTo field already handles most parent selection needs, and a small custom field is typically a couple hundred lines of code. The blocking question for a 0.0.0 package is the build-versus-adopt delta: what this solves that your own implementation would not. If the answer is only a slightly nicer select element, owning the code is usually cheaper than owning an unversioned dependency. Compare against the built-in field first, then against a thin custom field behind your own interface.
- Can I use nova-parental-field outside of Laravel Nova?
- No. It is a Nova field, so it depends on Nova's field lifecycle, form and index rendering, and the Nova package itself, which is a separate commercial dependency from Laravel. That coupling is fine if Nova is already part of your stack, but it means the field leaks into resource definitions rather than staying a portable domain concern. If you need portability, keep the relationship logic in your models and treat the field purely as a presentation layer. Nova version upgrades then become part of your compatibility matrix.
- Who maintains nova-parental-field, and is it actively maintained?
- The repository is published under the wamadev vendor, but maintainer identity, bus factor, and any support expectation are not documented. A single 0.0.0 tag with no release body or changelog suggests there is no established release process yet. Check commit history, tag cadence, and issue response times before committing, and consider vendoring or forking if the field becomes load-bearing. For anything long-lived, wrap it so you can swap the implementation in a sprint without touching domain code.