Nova Create Or Add Laravel Package

Technical Evaluation

Architecture fit. This is a leaf Nova field, not infrastructure. It registers a form control, publishes pre-compiled Vue assets, and reads/writes through the Eloquent relationship the app already owns. That makes it a clean fit for a sparse single-select relation (BelongsTo / MorphTo) inside Nova resource forms: no schema change, no data migration, and rollback is a one-line revert to native BelongsTo. It is a poor fit for core domain logic, BelongsToMany attach semantics, nested creation, or multi-record creation. The README claims HasMany support; treat that as unproven until the source read confirms it, because the safe scope described in diligence is single-select.

TPM framing: this should be treated as a reference-implementation decision, not a dependency adoption. At 9 stars, 0 dependents, and one maintainer, the realistic options are fork the pattern, reimplement it in-house (~1–2 dev-days), or stop if native Nova already covers the case.

Integration feasibility. Feasible as a field-for-field swap on one sparse BelongsTo, keeping the same foreign key column. The gates are: resolve provenance (Packagist shivanshrajpoot/nova-create-or-add vs GitHub Abhi0725/nova-create-or-add), verify composer.json constraints against the production Nova major, read src/, routes/, controllers, and resources/js/, then spike in staging. Native Nova must be ruled out first — BelongsTo::searchable() plus Nova’s built-in create-relation affordance may close the ticket at zero dependency cost.

Technical risk. Highest severity is authorization: inline creation embeds a write path in a form widget, and small Nova fields often post to custom search/create endpoints that skip the related model’s create policy. Second is silent failure: permissive version constraints can resolve cleanly and render a blank or inert field at runtime with no exception. Third is data integrity: create-then-attach is two operations, so without DB::transaction() you accumulate orphaned rows; without an idempotency guard, double-submit produces duplicates. Additional risks: stale pre-compiled assets after Nova upgrades, validation errors resetting the parent form and losing operator work, tenant-scoped search leakage, and bus factor of one.

Key questions.

• Which repository/package is canonical, and what Nova/Laravel constraints are declared?
• Does the field extend BelongsTo, and does the Vue side honor nullable, rules, search, and default behavior?
• Do create/search requests hit Nova’s standard resource routes, or a bespoke controller? At which layer is the related model’s create policy evaluated?
• Is create-then-attach wrapped in DB::transaction()? Is there a submit lock or server-side uniqueness guard?
• Is search tenant-scoped, paginated, and debounced?
• Does native Nova already solve the workflow? If not, who owns the fork, the smoke tests, and the Nova upgrade checklist?
• Is claimed HasMany support safe, or should scope be restricted to single-select?

Integration Approach

Stack fit. Laravel + Nova only. It fits existing Nova resource forms and has no fit for Filament, Inertia, or custom admin surfaces. Verify PHP, Laravel, and Nova version alignment before any engineering time is committed.

Migration path. No schema migration. Replace the native BelongsTo on one sparse relation, keep the foreign key, and roll back by reverting the field line. If the spike succeeds, vendor the package via a path repository or private VCS fork and pin it. Add Dependabot for laravel/nova and laravel/framework, and record the coupling on the Nova upgrade checklist.

Compatibility. Test three axes independently: Composer resolution (fast and loud), asset publish/build (medium, sometimes loud), and runtime behavior (slow and silent). Republish assets after any Nova upgrade and confirm the published asset hash changed. Run CI against the exact Nova version used in production.

Sequencing.

1. Timebox a native-Nova check (about 2 hours); stop if BelongsTo::searchable() plus built-in create already covers the workflow.
2. Resolve provenance and read the source in this order: src/, routes/ and controllers, resources/js/, composer.json and service provider.
3. Install in staging, publish assets, and swap one sparse BelongsTo.
4. Spike six paths: create new and attach; attach existing via search; inline validation failure preserving parent form state; policy denial on related model create; nullable relation left empty; double-submit produces no duplicate.
5. Decide build vs fork vs stop based on evidence. The in-house fallback is ~1–2 dev-days.
6. If proceeding, fork/pin and add smoke tests to CI.
7. Roll out behind a flag, one resource at a time. Enumerate all sparse relations to decide whether this is a per-field patch or a broader quick-create convention.
8. Record the decision, owner, rollback plan, and Nova upgrade coupling.

Operational Impact

Maintenance. TPM should treat this as an owned fork, not a vendor-supported dependency. Budget ~1 hour to vendor and pin, plus CI smoke tests, plus an entry on every Nova major upgrade. Each upgrade requires revalidating the PHP field class, the Vue component, and published assets.

Support. Bus factor is one and there is no community review. Engineering owns defects, policy patches, transaction boundaries, and idempotency fixes. Ops support impact is small if the UI stays native, but expect tickets phrased “I can’t find X” or duplicate-record reports if search/create behavior is flawed. Document troubleshooting: browser console first, network tab for search/create request scoping, then laravel.log for policy or validation exceptions.

Scaling. This is a UI widget; the scaling risk sits in the search endpoint. High-cardinality tables without pagination, debounce, and tenant scoping are both a performance and data-exposure problem. It is not appropriate for high-volume multi-record creation or BelongsToMany. Roll out per resource and measure time-to-create, support-ticket volume, orphaned-row counts, and duplicate-record incidents.

Failure modes and mitigations.

• Silent inert field after Nova upgrade or stale assets → republish assets, verify hash change, keep a runtime smoke test.
• Policy bypass on inline create → confirm standard Nova route or patch policy check into the controller before operators see it.
• Orphaned rows from failed attach → wrap create-then-attach in DB::transaction() in the fork.
• Duplicate rows on double-submit → add submit lock or server-side uniqueness guard.
• Parent form state loss on validation error → explicitly test in the spike; reject the field if state is reset.
• Tenant data leak via unscoped search → verify tenant-scoped, paginated, debounced search before rollout.

Ramp-up. Engineering needs roughly half a day to a day for the spike, tests, and fork; ops ramp-up is minimal because the control looks native. TPM governance should be a one-page decision record with success criteria — reduced time-to-create, fewer “can’t find X” tickets, zero orphan/duplicate incidents — a named owner, a rollback plan, and a Nova upgrade checkpoint. The low opportunity score reflects zero ecosystem leverage, not absence of user value; do not use it as the sole quality signal.