Nova Tabs Laravel Package

Technical Evaluation

Architecture fit

• Scope remains narrow and presentation-layer only: the package reorganizes Nova resource forms/detail views into tabbed sections. It does not touch persistence, auth, queues, or domain logic, so it slots into the Nova admin layer without disturbing application architecture.
• Nova itself is a commercial first-party package (paid license, closed source). Any third-party Nova extension is inherently coupled to Nova's internal field/component contracts, which are not covered by Laravel's backward-compatibility promise.
• Fit is good only if Nova is already a sanctioned part of the stack. If Nova is not licensed and in use, this package is irrelevant. Nothing in v2.31.0 changes this.

Integration feasibility

• Mechanically still trivial: composer require, register the tab field/panel class in a Nova resource, publish assets if required. Effort remains hours, not days, for a spike.
• Changed by v2.31.0: PHP 8.4 deprecation warnings are now fixed (PR #2). This removes a concrete blocker for teams already on PHP 8.4 and is the single strongest positive signal the package has produced. Previously the assessment had to treat PHP 8.4 as an open compatibility question; that is now largely closed.
• The blocking question is unchanged and is still Nova-side, not PHP-side: Nova 4/5 moved to Vue 3 and reworked field internals. A deprecation fix says nothing about whether the field renders correctly against current Nova point releases. No test suite, CI badge, or compatibility matrix is evidenced in the release.
• Note the release-discipline signal: a deprecation-only fix shipped as a minor bump (2.30.0 → 2.31.0). Harmless for ^2.30 constraints, but it suggests loose semver hygiene, so pin exact versions rather than ranges.

Technical risk

• Abandonment risk — revised, not resolved. The prior assessment characterized the repo as archived with zero community. v2.31.0 contradicts "archived": an outside contributor (@stefvanesch) had a PR reviewed and merged. That is real, if minimal, evidence of maintainer attention. However, the PR number (#2) confirms the repo has seen roughly two pull requests in its lifetime — this is a single drive-by contribution, not a maintained project. Reclassify from "archived/unmaintained" to "minimally maintained, bus factor 1, no support commitment."
• Contract risk (unchanged, still dominant): it wraps Nova's field rendering; a Nova minor upgrade can break layout, conditional-field visibility (dependsOn), file uploads, or validation display without any signal from the vendor.
• Correctness risk in the UI layer (unchanged): tabbed forms can hide required/validation-error fields on inactive tabs, producing "silent" failed saves. v2.31.0 does not touch this. Needs explicit verification, not assumption.
• Licensing/supply-chain (unchanged): verify the license permits internal forking. A newly-active low-scrutiny repo is still a low-scrutiny repo; a first-time contributor with merge rights is worth confirming is intentional and not an unreviewed permission grant.
• Overall: low blast radius if it fails (admin UI only), moderate-to-high probability of eventual failure, near-zero vendor recourse. Risk is marginally lower than in the prior assessment, not materially different.

Key questions

1. Which Nova major/minor versions are actually supported? Confirm against current Nova in a spike — v2.31.0 asserts nothing here.
2. Does it handle Nova's conditional fields, validation error surfacing, and file/image fields correctly on inactive tabs? (Still unaddressed by the release.)
3. What is the license, and are we permitted to fork and redistribute internally?
4. Is the new contributor a durable second maintainer or a one-off? Check whether PR review/merge cadence continues over the next 1–2 releases before treating the project as alive.
5. Is there a maintained alternative (Abordage/Eminiarts tab packages, or native Nova 4+ Panels for detail views) that removes the need for this dependency entirely?
6. Can the same UX be achieved with in-house Nova custom fields at acceptable cost, avoiding third-party coupling altogether?
7. Who internally would own a fork, and what is the exit trigger (Nova upgrade, first rendering bug, security advisory in the Nova ecosystem)?

Integration Approach

Stack fit

• Requires Laravel + a licensed Nova installation; Composer-native, no runtime services, no database migrations, no queue or config surface. Deployment footprint is published front-end assets only.
• Fits cleanly into an existing CI/CD pipeline; no new infrastructure. PHP 8.4 environments are now viable, which widens stack fit relative to the prior assessment.

Migration path

• Default recommendation softens but does not flip: still prefer not to adopt upstream as a live, unpinned dependency. Either (a) implement tabs with native Nova 4+ Panels where the target is detail views, or (b) vendor the source into an internal, namespaced package we control.
• The v2.31.0 release makes "adopt upstream with exact pinning" a defensible third option for a low-stakes internal admin use case — but only with an exact version pin (not ^2.30), a documented fork-on-first-breakage plan, and a named owner. It does not justify adopting on a version range.
• If the tabbed-form UX is genuinely required and no maintained alternative exists, fork as before: copy source into an internal repo, re-namespace, pin Nova/PHP constraints, register internally.

Compatibility

• Updated: PHP 8.4 is now supported as of v2.31.0 — drop that from the risk column, keep it in the version matrix as a verified item.
• Gate on a Nova version matrix spike: current Nova, current PHP (8.3 and 8.4), both a simple resource and a resource with conditional fields, file uploads, and required-field validation.
• Confirm the package does not require a Nova version we cannot pin, and that its asset build (Vite/Mix) matches our Nova version's expectations.

Sequencing

1. Confirm Nova license and current version; identify 2–3 representative resources for the spike.
2. Timeboxed spike (1–2 days) on the exact v2.31.0 tag.
3. Verify validation/error visibility, conditional fields, and mobile/accessibility behavior.
4. Decide: pin upstream, adopt fork, build in-house, or drop the feature in favor of longer forms/panels.
5. If adopted, add a CI smoke test asserting the field renders and a required-field error is visible on an inactive tab.
6. Re-review dependency health at the next upstream release; if no further activity within ~2 quarters, convert to fork regardless.

Operational Impact

Maintenance

• Still effectively internal ownership from day one. One merged external PR does not constitute a maintenance commitment, roadmap, or SLA. Budget a standing allowance per Nova upgrade cycle for regression triage.
• The codebase is small, so fork maintenance is likely low hours — but it is non-zero and permanent, and it lands on whoever owns the admin UI.
• Practical improvement: because PHP 8.4 deprecations are already resolved, we are less likely to inherit a mandatory patch on day one of an environment upgrade.

Support

• No vendor and no support contract. A single new contributor is not an escalation path; they may never contribute again. Internal support model: the owning team is the escalation path.
• Document the dependency in the internal register, downgrading the flag from "unmaintained upstream" to "minimally maintained, single maintainer, no SLA — internal owner required."

Scaling

• Negligible runtime scaling concerns: it is a render-time UI wrapper on admin pages used by staff, not customer traffic. No impact on application throughput.
• Organizational scaling concern is unchanged: every additional Nova resource using the package increases the surface area a future Nova upgrade must re-verify.

Failure modes

• Nova upgrade silently breaks tab rendering → fields invisible or duplicated in the admin UI; operators may enter incomplete records.
• Validation errors on hidden tabs → failed saves with no visible explanation; support tickets that look like application bugs.
• Asset build mismatch after a Nova front-end change → broken admin pages for all users of that resource.
• Newly relevant: an unreviewed future upstream release changes behavior with no compatibility matrix to check against — mitigated by exact version pinning and update-on-our-schedule.
• Mitigation: pin exact versions (lockfile + explicit constraint), deploy admin-UI smoke tests, and keep a documented rollback (revert to flat forms) that requires no data change.

Ramp-up

• Low: a Laravel developer familiar with Nova can read and modify the fork in under a day. PHP 8.4 support means no environment-level workaround is needed to get started.
• Onboarding cost is dominated by explaining why a low-activity package is vendored or pinned, which is worth writing down once in the repo README.

Bottom line for the TPM: v2.31.0 is a small but genuine positive — PHP 8.4 compatibility plus the first external contribution, which retires the "archived" characterization and meaningfully lowers the PHP-side risk. It does not address the actual dominant risks: untested compatibility against current Nova internals, silent validation failures on hidden tabs, and zero support commitment. Proceed only with an exact version pin or an internal fork, a named owner, and a defined exit trigger; otherwise replace with native Nova panels or in-house fields.