Nova Inline Morph To Laravel Package

Product Decisions This Supports

• Polymorphic data modeling — make it viable. morphTo relations (comments, attachments, activity logs, addressables, payments on a polymorphic parent) are frequently rejected in admin-UI scoping because they're expensive to render well. This field collapses that cost, so "do we model this polymorphically?" becomes a product/schema question rather than an admin-tooling budget question.
• Admin panel build vs. buy. A custom Nova field is roughly 1–3 senior dev-days plus recurring cost every Nova major upgrade. MIT-licensed and free to adopt = buy, with fork optionality. Relevant whenever a roadmap item includes internal tooling.
• Ops and support velocity. The value is clicks saved per admin session: faster ticket triage, moderation, refunds, and order/record fixes. Frame as time-to-resolve on internal workflows, not as a feature.
• Scope control on internal tools. Lets you ship a "good enough" ops back office and route engineering time to customer-facing surface instead of internal CRUD polish.
• Not a customer-facing decision. Zero direct revenue impact and no bearing on customer experience. Score it purely on internal-tooling ROI and maintenance risk.

When to Consider This Package

Adopt when all of these hold:

• You are already on Laravel Nova (paid license already sunk). This package has no value outside Nova.
• Your schema has, or is about to have, morphTo relationships that internal users need to view or edit, not just link to.
• The workflow is high-frequency for admins — the accumulated click savings is the entire value proposition. If the relation is touched monthly, don't bother.
• You have verified Nova major-version compatibility (field APIs changed between Nova 4 and Nova 5; last release is Dec 2024). Confirm against your installed major before committing.
• You accept the maintenance posture: ~34 stars, zero dependents, effectively a single maintainer. Treat it as a vendored convenience you're willing to fork and patch, not as infrastructure.

Look elsewhere when:

• You're not on Nova. Filament, custom Blade, or hand-rolled admin surfaces have different patterns; nothing here transfers.
• You need per-morph-type authorization/policy enforcement, cross-morph validation, or nested inline editing. Read the source first — thin Nova fields often punt on this and you end up rebuilding it with a worse starting point.
• You need vendor support or a compatibility guarantee. Zero dependents means no community canary; you are the QA and the upgrade path.
• The relation is rarely edited. A read-only link to the related resource is cheaper, simpler, and lower-risk.

How to Pitch It (Stakeholders)

Executives: A free, MIT-licensed UI component for the Nova admin panel we already pay for. It removes a known papercut: admins currently take extra navigation steps to see or edit records attached through polymorphic relationships. Cost is near zero — an install and a compatibility check. Risk is low: it's one field on internal tooling, trivially removable, and the MIT license lets us fork if the maintainer disappears. Don't schedule it as a roadmap item; book it as an ops-efficiency improvement.

Engineering: A drop-in Nova field that renders morphTo inline instead of forcing a jump to the related resource. Saves writing and maintaining a custom field (≈1–3 dev-days, plus churn at every Nova major). Validate in a short spike: Nova 4 vs. 5 compatibility, behavior with large candidate sets (searchable vs. plain select), per-morph-type policy/authorization handling, and whether inline edits correctly persist both the morph type and the ID. Pin the version, vendor or fork it if it becomes load-bearing, and keep a standard link field as the documented fallback.