Nova Tabs Laravel Package

Technical Evaluation

Architecture fit. Nova Tabs is a purely presentational wrapper around Nova's field composition model — it registers a compiled Vue bundle via Nova::script() and renders its children in <div v-show>/<div v-if> containers. There is no config file, no migration, no service class, and no persistence. That is the package's strongest property from a TPM standpoint: the blast radius of adoption is limited to Nova resource fields() methods. It fits cleanly wherever Nova is already the sanctioned admin surface and one or more resources carry 20–30+ fields. It does not fit public-facing UX, permission-aware or conditional workflows that need orchestration, or any admin stack that is not Nova.

Integration feasibility. composer require shuvroroy/nova-tabs:1.1.1 and a handful of fields() edits. Realistic estimate is 1–2 engineering days for a proof of concept on one resource, plus conventions and a regression pass. No data model change, no backfill, no API surface. This is a sprint-sized tactical convenience layer, not a platform decision.

Technical risk. The dominant risk is lifecycle, not functionality:

• Nova is proprietary and its extension APIs move across majors. Last release is 2023-11-15. The install must be treated as a pinned contract, and every Nova major upgrade is a gated change requiring regression-testing (and potentially patching) tabbed resources.
• Hidden validation errors are the one consequential behavioral quirk. A required field inside an inactive tab can make a form silently refuse to submit, because the package does not implement error routing. This is a product requirement to manage, not a bug to file.
• Thin real-world coverage. 9 stars, 0 dependents, single maintainer, patch-level release history only. Edge cases are unlikely to be pre-discovered for you.
• Asset bundle conflicts. Any other custom Nova tool or card shipping JS can produce tabs that render but do not switch, or duplicate Vue component registration.
• Accessibility is unverified. Do not assume keyboard tab navigation or screen-reader semantics exist.
• Mitigating factor: MIT license means a fork or in-house reimplementation is legally and practically viable. The downside is bounded and reversible.

Key questions.

1. Which Nova major are we on today, and what is the upgrade cadence we'd have to fund against it?
2. Which specific resources have 20+ fields, and are any of them business-critical or audit-sensitive?
3. Where do required fields currently sit in those resources — can they all live in tab one?
4. Do any tabbed surfaces carry accessibility obligations?
5. Does any existing Nova tool/card in our install already ship a Vue bundle?
6. Who is the named owner when Nova ships a major?
7. What is the success metric for the pilot — form completion time, validation-failure rate, or admin tickets per resource — and when do we read it?

Integration Approach

Stack fit. Laravel + Nova, PHP 8. Verify the package's composer.json constraint against the actual Nova major before anything else; the README shape and the vendored class signature are not guaranteed to agree.

Migration path. There is nothing to migrate. Rollback is removing the dependency and reverting fields() — no migrations, no data changes to unwind. This reversibility is what makes saying yes safe.

Compatibility work, in order of importance:

• Pin exactly (1.1.1 or a tight ~1.1.1) and commit the lock file. A floating constraint will silently acquire untested code on the next composer update.
• Read vendor/shuvroroy/nova-tabs/src/ directly — at this size the source is the documentation. Confirm the Tabs/Tab constructor and withFields() signatures, the service provider's asset registration, and whether the Vue component does anything on submit/error (it does not, per the source assessment).
• Load both the create form and the detail page. They render through different Nova code paths; one working while the other has a layout issue is a common outcome.
• Test conditional fields (dependsOn, ->hideWhenCreating()) explicitly inside tabs. They follow Nova's standard behavior, but visibility changes on an inactive tab give no visual feedback — keep dependent pairs in the same tab.
• Avoid naming a tab identically to a relationship on the same resource (the v1.1.1 slug-collision fix). Cheap insurance.
• Do not nest Tabs inside Tab. Use Nova's Panel::make() as the sanctioned sub-grouping escape hatch.

Sequencing.

1. Pin the version and read the vendored source.
2. Ship a one-file TabsField adapter that captures our defaults (ordering, fullWidth() conventions, canonical tab names). This converts "we depend on an unmaintained package" into "we depend on a one-file adapter" — swapping to a fork or in-house implementation later becomes a single-file change.
3. Pilot on one overloaded, non-business-critical resource.
4. Deliberately submit a form with a required field in tab three left empty, confirm the failure mode, and write the triage script before anyone else touches it.
5. Publish the tab taxonomy (General / Content / Relations / Meta) in the internal README.
6. Roll out in waves — broader adoption only after one clean Nova upgrade cycle.

Conventions to enforce in code review. Tabs::make() must be the only top-level element in fields(); anything else renders orphaned outside the strip. Extract each tab into a method so diffs stay readable and field shapes can be shared via traits. Keep relation tables in their own fullWidth() tab. Push rarely-edited computed fields into a Meta tab with onlyOnDetail() to keep form requests fast.

Operational Impact

Maintenance. Treat this as a frozen dependency, not a maintained one. Ownership must be explicit: a named engineer, a line in the Nova upgrade checklist ("regression-test tabbed resources"), and a small per-major budget of engineering days to validate or patch. The pre-agreed decision path — adopt / fork / replicate internally / defer — should exist before the pilot starts, not be discovered during an upgrade.

Support. The failure modes generate tickets, so instrument them up front:

• Silent non-submit. Give whoever triages admin tickets a one-line script: DevTools → Network → find the 422 response → read the body. It names every failing field regardless of active tab. This turns a 30-minute "is the admin broken?" investigation into a 30-second lookup. Better still, put required fields in the first tab so it rarely fires.
• Tabs render but don't switch. Debug via the browser console first; the compiled bundle filename is visible in the network tab. Test on a resource near other custom Nova JS during the pilot, not on a clean one.
• Onboarding friction. Dense forms generate tickets; tabs reduce them, but only if the taxonomy is consistent. Divergent naming ("General" vs "Overview" vs "Details") reintroduces exactly the cognitive load the feature removed. Write the vocabulary down once.

Scaling. Adoption scales linearly and cheaply — the cost is per-resource fields() edits, not infrastructure. Nova hydrates every field returned from fields() on form requests, so use tabs as an occasion to push expensive computed attributes behind onlyOnDetail(). There is no runtime dependency, no queue, no cache, no external service.

Failure modes, ranked by business impact.

1. Form silently refuses to submit (hidden 422). Highest frequency, highest confusion. Mitigate by convention + triage script.
2. Broken after a Nova major upgrade. Highest cost. Mitigate by pinning, gating the upgrade, and funding an owner.
3. Asset bundle conflict producing dead tabs. Mitigate by piloting alongside other Nova JS.
4. Accessibility gap on a tabbed surface. Mitigate by keeping obligated resources untabbed until verified.
5. Field resolution collision (tab named after a relation). Mitigate by staying on ≥1.1.1 and avoiding the naming pattern.

Ramp-up. Low. The API is Nova-native and idiomatic; a Nova-familiar engineer should be productive in half a day, and the two-day pilot estimate absorbs the source-reading and create/detail verification. The organizational ramp-up is the larger cost — agreeing tab names, the required-field convention, and the ownership model is a product conversation, not an engineering one, and skipping it produces five taxonomies and the same problem the feature was meant to solve.