Nova Polymorphic Field Laravel Package

Product Decisions This Supports

• Back-office feature scoping: expose polymorphic relationships in the admin or not. Many roadmap items — comments/notes attached to multiple content types, tags shared across entity types, media-library attachments, activity/audit trails, CMS blocks pointing at heterogeneous content — are cheap on the backend and expensive in the UI. This package decides whether admins can manage those relationships in Nova forms today, or whether the team defers the feature, ships read-only, or forces engineers into tinker/seeders. That is a scope decision, not a technical one.

• Build vs. buy vs. fork, with a small price tag. The capability is roughly one to two developer days for a competent Laravel dev. That makes this a small, reversible decision rather than an architecture commitment — but frame it as "fork and vendor" rather than "add a dependency," given the release history. The cost is measured in days, not budget cycles, so it shouldn't consume a planning cycle of its own.

• Make-vs-native roadmap call. Nova 4+ ships a native MorphTo field that covers much of this ground. Before any spike, verify against the pinned Nova version. If the platform already does it, the decision is "use the platform" and this package is a non-option — close it out and move on.

• Upgrade planning and the maintenance tax. A 2020-era Nova field is a known blocker for Nova major upgrades (v3 → v4 → v5) and for Laravel/PHP bumps. Adopting it adds a line item to every future framework upgrade. The PM question is whether the saved dev days now are worth that recurring tax — and the honest answer is usually yes only for a narrow window on an older Nova.

• Dependency inventory / vendor risk register. Zero Packagist dependents and 66 stars means no ecosystem validation: no downstream projects will absorb the maintenance burden or surface compatibility fixes for you. It belongs on the "internal, unsupported, at-risk" list from day one, with a named owner.

• Security posture as a tiebreaker. This is admin-panel-only surface area behind Nova's auth and policies, which materially lowers the blast radius of an unmaintained package compared to anything customer-facing. That is the main argument in its favor and the reason a fork is defensible at all.

• Repetition as the ROI signal. If the same polymorphic selector shows up across several Nova resources, a shared field beats hand-rolled per-resource code. If it's one screen, build it inline and skip the dependency entirely.

When to Consider This Package

Adopt (as a fork or vendored snippet) when:

• You are on Laravel Nova 2 or 3, on a PHP/Laravel version the package's constraints still resolve against, and a native equivalent isn't available.
• You need the same polymorphic selector repeated across several Nova resources — repetition is where a shared field earns its keep.
• You have at least one PHP developer who can read the source, add tests, and own it indefinitely.
• The feature is internal-only, non-revenue-critical, and can be dropped without customer impact.
• Your procurement/security process does not require a supported vendor or an SLA.

Look elsewhere (or build it) when:

• You are on Nova 4 or 5 — start with the native MorphTo field and only revisit if it genuinely falls short.
• You need search, inline creation, or per-type authorization beyond what a simple type-plus-resource selector gives you.
• You require active maintenance, security patching, or a support contract. Last release 2020-05-04 with no subsequent activity is a hard stop for anything with a compliance owner.
• Nobody on the team owns PHP/Nova long-term, or the admin is maintained by an agency that will not carry a fork.
• The package's composer.json constraints exclude your PHP/Laravel version — with five years of drift, assume incompatibility until proven otherwise, and do not plan on a fix arriving upstream.
• The capability is customer-facing rather than admin-only.

Go/no-go gate before any spike: confirm the package installs and the field renders on your exact Nova + Laravel + PHP matrix. Budget half a day, and treat a failed install as a decision, not a problem to solve. Do not use --ignore-platform-reqs in production as a workaround — it hides incompatibility rather than resolving it.

How to Pitch It (Stakeholders)

One line: A small, free (MIT) Nova field that lets admins attach records to any of several model types from a single form — useful, but effectively abandoned since 2020, so we'd take it as source code we own rather than as a dependency we rely on.

For executives: This is not a strategic purchase — there is no license cost and no vendor relationship to manage. The question is whether ~1–2 developer days of saved work justifies carrying an unmaintained component. Our recommendation is conditional: use it only if we're on an older Nova version where the platform doesn't already do this, and only in the admin panel, where the security exposure is contained. Otherwise we use Nova's built-in field or build it ourselves. Either way the cost is measured in days, not budget cycles, and the decision is reversible.

For engineering: Treat michielkempen/nova-polymorphic-field as a code sample, not a library. Fork it into our repo, pin the version by tag or commit, add a smoke test, and document the owner and the patch set. Do not let it become a transitive dependency of a shared internal package — with zero dependents upstream, we are the only ones who will ever notice it breaking. Mirror any conditional validation server-side in a FormRequest, because UI-only logic is a validation bypass waiting to happen. Before forking, spend 30 minutes confirming Nova's native MorphTo field doesn't already cover the requirement; if it does, we close this out.

Recommendation: Conditional adopt / fork. Do not adopt as a long-lived Composer dependency, pilot on one low-risk Nova resource, and revisit at the next Nova major upgrade with a documented fallback to native fields.