Nova Dependable Panel Laravel Package

Technical Evaluation

Architecture fit. formfeed-uk/nova-dependable-panel is a Laravel Nova extension — a Vue-backed panel/container that adds conditional ("depends on") visibility logic to fields rendered inside it. It sits entirely in the presentation layer of the Nova admin panel and does not touch application runtime, routing, Eloquent models, or queue/console paths. Fit is therefore narrow but clean: it only matters if the product already runs Nova as its back-office, and it delivers value only where form UX currently relies on hand-rolled dependsOn chains or canSee closures that are hard to maintain.

Integration feasibility. Installation is a standard Composer require plus Nova's package discovery; usage is declarative in NovaServiceProvider/resource fields(). No database migrations, no config publishing expected, no external services. Effort to a working spike is measured in hours, not days.

Technical risk. Release 1.2.3 is a single-line patch — "fix: issue with array keys" — which is a strong signal that the dependency-resolution path had an indexing defect for multi-value source fields (BooleanGroup, MultiSelect, Checkbox/CheckboxList, or keyed option arrays). Low blast radius, but two caveats: (a) the fix implies the array-key path was previously unreliable, so any form depending on multi-value fields should be treated as freshly-changed behaviour and regression-tested rather than assumed identical; (b) it is a patch on a small, single-maintainer package, so the correctness guarantee rests on that maintainer's test coverage, which we have not inspected.

Key questions.

• Which Nova major versions (4.x / 5.x) and PHP/Laravel ranges are supported, and is that stated in composer.json constraints or only in the README?
• Does the array-key fix change observable behaviour for existing configurations (i.e. do previously "always visible" fields now correctly hide), and is that documented?
• Is there an automated test suite and CI, and does it cover array-valued dependencies?
• What is the licence, and is the package maintained actively enough to survive the next Nova major (Nova 5 introduced panel/field container changes)?
• Does it compose with nested panels, dependsOn on non-field components (tabs, cards), and Nova's ->canSee() precedence rules?

Integration Approach

Stack fit. Only applicable to the Nova admin surface of the Laravel app. It must not be introduced into customer-facing views, API resources, or any Blade/Inertia front end — those are unaffected by and incompatible with this package. Confirm the app is on Nova (not Filament/Backpack) before any work is scheduled.

Migration path. Additive, not a migration. Bump formfeed-uk/nova-dependable-panel from 1.2.2 to 1.2.3 in composer.json, commit the lockfile, and deploy through the normal release pipeline. Because Nova assets are compiled, the deploy must include the Nova asset publish/build step; a Composer-only deploy will leave stale JS in public/vendor/.

Compatibility. Semver patch, so no API breakage expected. Verify the composer.json constraint against the installed Nova version and PHP version before merging. If the app pins Nova 4 while the package's latest constraint targets Nova 5, pin the package to the last compatible tag rather than force-resolving.

Sequencing.

1. Staging bump to 1.2.3 with asset rebuild; smoke-test any resource using a dependable panel.
2. Targeted regression pass on forms whose dependency source is an array-valued field — this is precisely the surface the fix touches. Confirm show/hide behaviour for empty array, single-element array, and multi-element array states, plus the "edit an existing record with pre-populated values" path.
3. Only then promote to production; keep 1.2.2 as the documented rollback tag.
4. Treat broader adoption (converting existing canSee closures to dependable panels) as a separate, later change so the version bump and the refactor are not entangled in one rollback boundary.

Operational Impact

Maintenance. Low ongoing cost by volume — the package is a thin UI wrapper with infrequent releases — but the maintenance risk is concentrated in a single maintainer at Formfeed-UK. Budget for the possibility of abandonment: keep the dependency optional and behind a small number of resource files so it can be removed or vendored without a wide refactor.

Support. GitHub issues only; no commercial SLA, no security advisory process observed. Acceptable for an internal admin tool; not acceptable as a dependency anything customer-facing or compliance-critical rests on.

Scaling. Negligible server-side impact — dependency evaluation happens client-side in the Nova SPA. The only scaling consideration is form complexity: heavily nested dependable panels on large resources (hundreds of fields) can add render latency and make behaviour harder to reason about. Prefer flat panels per tab over deep nesting.

Failure modes.

• Silent non-reactivity: fields fail to show/hide after a Nova upgrade because the panel's JS assumptions about Nova's component internals changed — fails quietly, so add a smoke check rather than relying on error monitoring.
• Stale assets: version bumped but Nova assets not rebuilt, leaving the old (buggy) array-key behaviour in production while Composer reports 1.2.3.
• Over-hiding: an array-key edge case (empty array treated as populated, or vice versa) hides a required field, producing validation errors users cannot see the cause of.
• Version drift: a transitive Nova upgrade silently violates the package's untested compatibility range.

Ramp-up. Low. The declarative API is a few methods on a panel/field, so a Laravel developer familiar with Nova is productive within an hour and a half, and the concept maps onto the dependsOn/canSee mental model most Nova developers already hold. The non-obvious learning is the interaction between panel-level dependency logic and Nova's own visibility rules — document the team's chosen precedence convention once, in the repo, so it does not get re-litigated per resource.