Laravel Nova Morph Many To One Laravel Package

Product Decisions This Supports

• Feature-level admin UX: this package exists to make one interaction possible — attaching existing related records across a morphMany relation from a Nova detail screen, instead of forcing editors to re-create records inline. That unlocks workflows like "attach an existing document/media asset/comment thread to this parent record," which stock Nova relationship fields don't handle well for polymorphic relations.
• Data-quality outcomes, not just UI: the product value is deduplication. When the only path to a polymorphic relation is create-inline, admins copy-paste records into existence. Search-and-attach lets one canonical record serve many parents, which improves reporting integrity, reduces orphan/duplicate cleanup, and shortens time-to-complete for repetitive ops tasks.
• Roadmap weight: low, and should be recorded as such. This is internal back-office tooling — an internal throughput lever measured in hours saved per admin per week, not a customer-facing capability. Don't let it occupy roadmap space; it's a build-vs-buy line item inside an admin-panel epic.
• Build vs buy is really adopt vs vendor. The package is MIT, archived, 2 stars, 0 dependents, and its last release (May 2024, Laravel 11 support) is the terminal one. So the honest decision isn't "buy" — it's "borrow the source and own it." The footprint is small (a Nova field plus Eloquent glue); vendoring it is a day of engineering and converts a dead upstream into a small owned utility.
• Decisions it should not drive: it must never become the reason a Laravel or Nova upgrade slips. If an admin convenience field is the sole blocker on a framework upgrade, that's the trigger to fork or replace — not to defer the upgrade.
• Use cases where it earns its place: internal ops/admin panels, content and asset curation, back-office data cleanup, and migration-era administration where the polymorphic modeling is still settling and you need editors productive before the schema is final.

When to Consider This Package

Adopt only if all of these hold:

• We run Laravel Nova. This is a Nova field. No Nova, no value — evaluate the Eloquent piece separately and only if it's genuinely reusable.
• At least one real morphMany relation exists where child records pre-exist and are legitimately shared across parents. If every child is created for exactly one parent, create-inline is the correct UX and this adds nothing.
• The surface is internal and low-blast-radius. A broken field means an annoyed ops team, not a customer incident.
• We are on Laravel 11 and staying there for now. 0.4.0 is both the Laravel 11 entry point and the last release ever.
• We're willing to vendor it. MIT permits it; the archive status requires it.

Look elsewhere — or decline — if any of these hold:

• Laravel 12+ is on the roadmap. Archived project, no further releases; this will become a hard ceiling on the framework version.
• The relation is actually belongsToMany/morphToMany. Model it correctly rather than bending a morphMany into many-to-one semantics.
• The surface touches PII, payments, auth, or regulated data. 2 stars, 0 dependents, archived, no security disclosure process, no issue-response evidence. There is no support corpus to lean on — no Stack Overflow answers, no third-party bug reports.
• We're evaluating leaving Nova (Filament, custom admin). Don't take on Nova-specific lock-in mid-platform-decision.
• We need an SLA, vendor support, or a documented deprecation policy. None exist.
• No one can be named as owner of the fork's upgrade calendar and periodic health check. Unowned forks rot silently.

Treat the version as pinned-permanently-until-forked. Because it's pre-1.0 and now frozen, there's no upgrade path to plan for — only a fork to maintain.

How to Pitch It (Stakeholders)

For executives: A small, free (MIT), internal-only admin capability that lets ops staff attach existing records instead of re-keying duplicates — better data quality, faster admin tasks, no customer-facing surface. Adopting it costs roughly a day of engineering and carries near-zero runtime risk, because it's a Nova field on internal screens rather than anything in the request path of the product. The caveat, stated plainly: the upstream project is archived, has essentially no adoption (2 stars, 0 dependents), and will never support Laravel 12. The recommendation is therefore not "add a dependency" but "borrow the source and own it" — vendor the field into our codebase, keep our own copy, add our own tests. That turns a dead dependency into a small owned utility, removes the framework-upgrade risk entirely, and still delivers the admin workflow this quarter. It should not be treated as a strategic or long-lived third-party dependency, and it should not appear on the roadmap as a feature.

For engineering: It's a Nova field plus Eloquent glue that renders morphMany as a searchable many-to-one selector on create and update forms. Before touching the main app: read the source (it's small), and if you install it at all, diff the composer.json constraint to confirm 0.4.0 widened illuminate/* rather than replaced it, and check the minimum PHP against our runtime. Then copy the field and trait into our app, write tests around attach, detach, and search behaviour, and drop the composer requirement. Two compatibility axes matter and only one is covered by the Laravel version number — Nova itself is closed-source, so pin and test against our specific Nova version explicitly. If we ever do install it, pin exactly and disable auto-merge on the dependency bot; under 0.x semver, every routine bump is a potential breaking change requiring human review.