Nova Morph To Create Field Laravel Package

Product Decisions This Supports

• Admin workflow friction vs. engineering cost: Quantifies a specific inefficiency — operators who must leave a Nova form, create a polymorphic parent record elsewhere, and return — and frames the fix as a narrow UI-field investment rather than a platform initiative. Use it to decide whether the round-trip cost is worth a small dependency.
• Build vs. buy vs. vendor for a single capability: The capability (inline create on a MorphTo field) is small enough to implement in-house but tedious enough to be underestimated. This package supports the "buy cheap, plan to vendor" path: adopt under MIT, audit the ~1-class codebase, and keep a fork budgeted rather than treating it as a permanent vendor relationship.
• Roadmap placement for internal tooling: Justifies a time-boxed pilot inside an admin panel — not a customer-facing surface — where a click reduction has measurable operator value and zero customer blast radius. It is a candidate for a backlog item labeled "internal UX," not "platform dependency."
• Use-case fit triage: Best where the polymorphic relation is shallow (a comment on a post or video, an attachment on multiple parents, an activity target) and the inline-created record needs only a handful of fields. Poor fit where creation requires complex nested forms, multi-step validation, or per-type permission logic.
• Vendor-risk posture: Explicitly supports a decision to pin, vendor, or fork. At 1 star and 0 dependents, the PM should assume no upgrade path and treat maintenance ownership as part of the adoption cost — this is the single most important product judgment the package forces.
• Create-vs-update surface scoping: Supports a deliberate product choice to expose inline creation only on the create form, leaving updates on Nova's stock MorphTo. That limits exposure to an unmaintained field while still capturing most of the user benefit (users create against fresh parents far more often than they re-parent existing records).

When to Consider This Package

• The product runs on Laravel Nova, and operators routinely need to create a polymorphic related record from a resource form. No Nova, no case.
• The relationship is genuinely MorphTo on the child resource (the resource owns the relation), with a small number of morph types — realistically two to four — and stable aliases enforced via Relation::enforceMorphMap().
• You can tolerate low community validation: 1 star, 0 dependents, no release cadence, single maintainer. Adoption must come with a named internal owner for the fork.
• Engineering can audit, pin, vendor, and test the field. Verify first: Nova major compatibility (v4 vs v5 field signatures differ), the real FQCN in src/ (maturity-level packages routinely ship namespaces that don't match the README), whether the create path routes through Nova resource authorization, and whether it preserves searchable, nullable, morphWith, and morphWithCount semantics.
• Look elsewhere if core Nova already covers the flow in your version, if the relation needs complex nested creation or granular per-type permissions, or if the admin experience demands enterprise-grade vendor support or compliance sign-off on maintained dependencies.
• Look elsewhere if the team cannot own a low-adoption dependency, or if the morph types have tenant-scoped or soft-deleted parents where inline search would silently return empty results and look like a bug.
• Do not consider it on the index view — an index column of MorphTo values costs one query per morph type and the create affordance makes no sense there. Restrict it to form contexts.

How to Pitch It (Stakeholders)

• To executives: This is a small, low-cost admin productivity enhancement, not a strategic platform bet. It removes a navigation round-trip for operators working with polymorphic records in Nova. The trade-off is dependency risk: the package is MIT-licensed but effectively unmaintained, with negligible adoption. Recommend a narrow, time-boxed pilot in one admin workflow rather than a broad rollout.
• To engineering: An MIT Nova field that extends MorphTo with an inline create modal. The codebase is small enough to read end-to-end and fork. Before adopting, confirm Nova version compatibility, that inline creation defers to Nova policies for both the child and the parent resource, and how morph aliases map to target Nova resources. Pin the version, add a test asserting the persisted *_type/*_id pair, and plan to vendor the field class into app/Nova/Fields/ the moment you need a change.
• Recommendation: Treat it as an optional internal-tooling component. Run a one-workflow pilot, verify authorization and validation behavior end-to-end (not just that the form renders), and adopt only if it demonstrably saves operator time. Otherwise implement the narrow behavior in-house or wait for core Nova support — either is a defensible answer given the stewardship risk.