Nova Create Or Add Laravel Package

Product Decisions This Supports

• Admin workflow friction vs. tooling investment. The package targets one specific dead end in Laravel Nova: an operator filling out a form needs a related record that doesn't exist yet, and the native BelongsTo field forces a context switch (save parent → navigate → create child → return) or a silent validation failure. The decision it informs is narrow but measurable — "is reducing operator context-switching worth engineering time?" — and can be tracked in time-to-create for parent records and in support tickets phrased "I can't find X in the dropdown."
• Build vs. buy vs. reimplement-the-pattern. At 9 stars, 0 dependents, and a single maintainer, this is not really an adoption decision — it's a reference-implementation decision. Read the source, then either fork it into the app's Nova namespace or rebuild the behavior in-house. Both land at roughly 1–2 dev-days, which keeps the conversation about ownership cost and reversibility rather than package quality.
• Consolidated quick-create convention vs. per-field patches. Use the package as a forcing function: enumerate every Nova relation whose target table is sparse or frequently empty (tags, authors, categories, vendors, contacts). A short list argues for a one-off patch; a long list argues for a single "quick-create" convention across resources — a different and larger piece of roadmap work, and one that should be scoped before any dependency is taken.
• Nova upgrade planning. Adopting this field converts it into a pin on the current Nova major. Third-party Nova fields ship pre-compiled Vue assets that fail silently when Nova's internal component API shifts between majors (3 / 4 / 5). That's a roadmap input for the next upgrade, not just a line on the dependency list — record it on the upgrade checklist alongside the Dependabot watch on laravel/nova.
• Reference implementation for adjacent admin tooling. Even if this package is never installed, its source is a cheap design template for the same interaction in Filament, Inertia, or a custom admin. If the team ever migrates off Nova, the pattern (searchable select + inline create + attach) survives the migration; the package does not.
• Market-signal caveat. The low opportunity score (~22) should not be read as "bad package." Nova is a paid, closed-source product with a bounded audience, and this solves a narrow slice of it. The score reflects zero ecosystem leverage — no reason to depend on it long-term — not an absence of user value.

When to Consider This Package

Evaluate it only when all of the following hold:

• You are on Laravel Nova, and you've verified the field's composer.json constraint against your Nova major. A permissive or missing constraint (*) is a red flag, not a green light — it usually means compatibility was never reasoned about.
• The affected relation is single-select (BelongsTo / MorphTo). For BelongsToMany attach semantics, nested creation, or multi-record creation, this is the wrong tool — route that to a Nova action or a custom tool.
• Operators hit the missing-related-record path often enough that the context switch is a recurring cost, not a quarterly annoyance.
• An engineer is willing to own a fork: vendor it into a packages/ path repository or private VCS fork, pin it, and add a smoke test covering create, attach-existing, validation failure, and policy denial.

Look elsewhere — or ship nothing — when:

• Native Nova already covers it. BelongsTo::searchable() plus Nova's built-in create-relation affordance handles the common case. Verify first; it's free, supported, and gates everything else. If it works, close the ticket — that's a two-hour check well spent.
• You need validation, authorization, or event parity. If inline creation must honor the related resource's full rules, policies, and model events, a thin field wrapper typically doesn't — and you inherit orphaned or half-valid records written outside the paths the rest of the app trusts. Read routes/ and any controllers before the README: a bespoke create endpoint that skips the policy layer is the highest-severity finding in a diligence pass like this.
• You need transactional create-then-attach, idempotency on double-submit, or tenant-scoped search. If the source shows no DB::transaction() boundary or an unscoped search endpoint on a high-cardinality table, build the minimal in-house field instead — replacement cost stays 1–2 dev-days.
• You're not on Nova. The problem class largely disappears in a custom Filament or Inertia admin, where the ecosystem is more active and abandonment risk is lower.
• The surface is revenue-critical and nobody will own the fork. A bus factor of one plus zero community review of the surface is a pricing input, not a dealbreaker — but it means the fork has to have an owner.

How to Pitch It (Stakeholders)

To executives: This is a small ergonomics fix for our internal admin tooling — it lets ops staff create a missing related record without leaving the form they're already on. It's not customer-facing and not a strategic bet. Cost is roughly a day of engineering whichever route we take, and it's fully reversible: the field drops in as a one-line swap against the native BelongsTo we already use, and rolls back the same way. Recommendation: vendor the pattern rather than take a direct dependency on a nine-star, single-maintainer package. Low upside, low downside, bounded cost.

To engineering: Treat this as a source read first, install second. The valuable part is the interaction pattern, not the artifact. Concretely: confirm the PHP field extends BelongsTo (so we inherit search, nullable, and rules behavior), confirm the inline create posts through Nova's standard resource store route so the related model's create policy and validation actually run, and confirm create-then-attach is wrapped in a transaction. If any of those three checks fail, fork and patch — it's cheaper than reimplementing. Then vendor it, pin it, add Dependabot for laravel/nova and laravel/framework, and put a six-path smoke test in CI (create, attach-existing, validation failure preserving parent form state, policy denial, nullable left empty, double-submit producing no duplicate). Roll out behind a flag, one resource at a time, and remember the classic silent failure mode: a stale published asset after a Nova upgrade, where the field simply stops responding with no exception and no log line.

To the operations team: The change you'll notice is that you stop losing your work. Today, when the vendor or contact you need isn't in the dropdown, you either abandon the form to go create it or you get bounced on save. After this, you create it inline and keep going — one flow instead of three screens. We'll pilot it on one resource first, and if the inline-create validation errors ever wipe a half-typed form, tell us immediately; that's the failure mode we care most about and it's the one we'll be testing for.