Weave Code
Nova Dynamic Resources Laravel Package
opscale-co/nova-dynamic-resources
Opscale's Nova Dynamic Resources lets you define Laravel Nova resources at runtime from configuration or database tables, generating dynamic fields, filters, actions, and metrics—eliminating repetitive boilerplate resource classes and speeding up admin panel development.
At a glance
Frequently asked questions about Nova Dynamic Resources
- How do I install opscale-co/nova-dynamic-resources in a Laravel Nova application?
- Install it with Composer using composer require opscale-co/nova-dynamic-resources, then let Laravel's package auto-discovery register the service provider. Publish the package config with vendor:publish and review the defaults before defining any dynamic schema. Nova must already be installed and working, since this package extends Nova rather than replacing it.
- Which Laravel and Nova versions does nova-dynamic-resources support?
- The package follows the standard Laravel package conventions, so its supported Laravel and Nova ranges are declared in its composer.json constraints. Check those constraints against the Nova major version already running in your application before pinning. The v1.12.0 release note does not advertise any changed version requirements, but you should still confirm the installed Nova major stays inside the supported range after upgrading.
- Can I define a Nova resource at runtime from a database table instead of writing a PHP resource class?
- Yes. The package lets you describe resources through configuration or database tables, and it generates the dynamic fields, filters, actions and metrics from that definition instead of requiring a hand-written PHP class. This is aimed at teams with many similar resources where boilerplate classes become repetitive. The generated resources plug into the normal Nova bootstrapping flow, so your application's domain layer is not modified.
- How does the catalog-backed multiselect field added in v1.12.0 work?
- Version 1.12.0 adds a multiselect field type whose option set comes from application data, such as a taxonomy, product catalog or lookup table, rather than being enumerated in code. Because the field is surfaced through the package's dynamic schema, it needs no changes to your controllers or routes. The main integration step is confirming that the package's option resolution path matches how your application models its catalogs, whether that is an Eloquent model, a query or a custom resolver.
- How are multiselect values stored in the database, and will my API resources handle them?
- Multiselect fields persist arrays, so the target column needs a JSON or text cast, or a pivot table if you prefer a relational representation. Any API resources, exports or Nova detail views that consume those fields must accept array payloads. Store stable identifiers rather than labels so renamed catalog entries do not corrupt existing selections, and decide early how deleted entries should be treated.
- Does the catalog-backed multiselect field support server-side search and pagination for large catalogs?
- The v1.12.0 release note does not document search, pagination or default option limits, so this needs to be verified against the package source and your own dataset. Catalog-backed option loading on large tables is the main performance risk of this feature, since unbounded option queries on index and detail views can produce N+1 or slow requests. Benchmark query counts in staging with a realistic catalog size before rolling the field out broadly.
- Is there built-in validation for maximum selections, allowed values and orphaned catalog IDs?
- Validation, null handling and maximum selection behaviour are not described in the release note, so treat them as undocumented until you confirm them in the code. As a safeguard, attach explicit Nova validation rules such as array, max and exists against the catalog table for fields that adopt the new type. Also define what happens when a referenced catalog entry is deleted, since orphaned IDs otherwise surface as blank options.
- Is upgrading from 1.11.x to 1.12.0 a breaking change?
- Version 1.12.0 is a minor, feature-only release, so breaking-change risk is low and no migrations are required for existing field definitions. Adoption is opt-in per field, which means existing dynamic resources keep working untouched. Pin to ^1.12 in composer.json, update on a branch, and validate the pilot field in staging before merging.
- When should I use dynamic resources instead of hand-written Nova resource classes, and can both coexist?
- Use dynamic resources when many Nova resources share a repetitive shape and their fields are better described as configuration or data than as PHP. Hand-written classes remain a reasonable choice for complex, highly customised resources with bespoke logic. The two approaches coexist cleanly because the package is additive and does not alter your existing Nova installation or domain layer.
- How should I test and roll out the multiselect field in a production Laravel application?
- Add a single pilot field of the new multiselect type to a non-critical resource on a branch, then confirm storage, serialization and query behaviour in staging. Check that array payloads survive your API resources and exports, and measure the query count for the option load against a realistic catalog. Roll out to the remaining resources only after the pilot is validated, including how renamed and deleted catalog entries render.
Weaver
How can I help you explore Laravel packages today?