Laravel Nova Morph Many To One Laravel Package

Technical Evaluation

Evidence base and correction to prior assessment: The prior assessment inferred an active maintainer from the 0.4.0 "Laravel 11 compatibility" note and framed the package as a healthy, if pre-1.0, dependency. The repository metadata contradicts that: the repo is archived, it has 2 stars, 0 dependents, and the last release (2024-05-11) is the terminal state of the project. Archival is not a soft signal — it means no further commits, no issue triage, no security patches, and no compatibility work for future Laravel or Nova majors. Any evaluation must start from "this is a frozen artifact," not "this is a maintained library."

Architecture fit: The package spans two layers with different risk profiles. The Eloquent layer adds a helper for treating a morphMany as a many-to-one attach/detach selector (the inverse direction Nova and Eloquent lack first-class support for). The Nova layer is a custom Field implementation, which means it binds to Nova's internal field, search, and relatable contracts. Nova is commercial, closed-source software with its own release cadence independent of Laravel's; Nova majors (4 → 5) have historically changed field internals. A custom Nova field is therefore the highest-coupling, least-contracted integration surface in the Laravel ecosystem — the package is betting on undocumented internals that the vendor can change without notice. The Eloquent half is benign if it is a trait/relationship helper and does not impose schema changes; confirm this, because a package that expects specific polymorphic column layouts is materially harder to unwind.

Integration feasibility: Technically straightforward if versions align — this is a small, single-purpose package and the install is a normal Composer require plus field registration in a Nova resource. The feasibility question is not "can we install it" but "can we support it." Because Nova is licensed per major and the package is archived, feasibility collapses to a single gate: does the package's declared Nova constraint include the Nova major we run, and will it ever include the next one? The answer to the second half is definitively no. MIT licensing means we can fork, which is the only durable path.

Technical risk: High, concentrated in four areas. (1) Archival — the dominant risk; every other risk is a consequence of it. (2) Nova coupling — the field will silently degrade or break on a Nova upgrade with no upstream fix forthcoming, and Nova's closed-source nature makes the failure hard to diagnose. (3) Zero adoption evidence — 2 stars and 0 dependents means effectively no community testing; the code path we exercise may be the first it has seen outside the author's app. (4) Pre-1.0 (0.4.0) — no API stability contract, though this is largely moot given the project is frozen. Mitigating factor: the code surface is small enough to read in an afternoon and fork in a day, which converts the risk from "unbounded" to "bounded and owned."

Key questions:

• What are the exact composer.json constraints for laravel/nova, illuminate/*, and PHP? Does it support Nova 5, or only Nova 4?
• Did 0.4.0 widen or replace the Laravel constraint, and were there behavioural code changes alongside it?
• Is the Eloquent half a trait/relationship helper or does it require a specific schema (type/id column naming, pivot tables)?
• Does the field respect Nova authorization and policies, or does it bypass them when attaching records?
• How does attach behave on the create form, where the parent model has no primary key yet? Is there a documented two-step save, or does it silently no-op?
• How is "searchable" implemented — server-side search with pagination, or client-side candidate loading that degrades on large morph tables?
• Are there maintained forks or downstream patches? Is there a published issue history documenting known breakage on Nova 5?
• What is the maintainer's stated reason for archival (if any), and does it imply "done" or "abandoned"?

Integration Approach

Stack fit: Narrow but sharp. This package has value only if (a) we run Laravel + Nova, and (b) we have morphMany relations where the desired admin UX is attaching existing records rather than creating them inline. If our Nova resources have no polymorphic one-to-many relations, the package is irrelevant regardless of quality. If we do have that gap, the alternative is building the field ourselves — and at this size, build-vs-adopt is a genuine coin flip that should be decided on ownership appetite, not on effort.

Migration path: The realistic path is not "add a dependency." It is one of three, decided up front:

1. Spike only — install in a scratch Nova app to evaluate behaviour, discard.
2. Vendor/fork — adopt the MIT code into an internal package under our namespace, pinning it to our Nova and Laravel versions. This is the recommended path if we adopt at all, because it makes ownership explicit before the first incident rather than after.
3. Reimplement — treat the repo as a reference implementation and write a minimal field against our exact Nova version. Viable given the small surface; costs more upfront, yields the cleanest long-term posture.

Installing it unmodified as a long-lived production dependency is the one option to reject: it transfers a frozen third-party artifact into our critical admin path with no upstream to escalate to.

Compatibility: Validate three axes independently, in this order:

• Nova major (the binding constraint, and the one most likely to fail): confirm the laravel/nova constraint in composer.json and that our licensed Nova version satisfies it.
• Laravel major: confirm the illuminate/* constraint covers our runtime; note that Nova's own Laravel support window constrains this further.
• PHP version: check the minimum against our runtime.

Do this in a scratch environment with composer why-not before touching the application. A transitive constraint pinning an older illuminate/* or laravel/nova will resolve "successfully" to an older stack and produce confusing runtime failures far from the cause.

Sequencing:

1. Needs validation (hours): confirm we actually have morphMany relations needing attach-existing UX. If not, stop.
2. Source and constraint review (hours): read composer.json, the field class, and the Eloquent helper. Confirm no schema assumptions.
3. Scratch spike (days): exercise create-form attach, update-form attach/detach, searchable selection at realistic table size, and policy/authorization behaviour.
4. Decision gate: fork-and-own vs. reimplement vs. no-go. Record the decision and the rationale; this is the artifact that justifies the choice at the next audit.
5. Adoption (if applicable): internal namespace, exact pin, canary environment, documented rollback to the pre-adoption Nova resource.

Operational Impact

Maintenance: Ownership transfers to us on day one, regardless of whether we "adopted" it. There is no upstream to file against. Budget: a one-time fork/absorption cost (small, days) plus a recurring re-validation at every Nova major — a standing line item, not a one-off. Because Nova upgrades are typically gated on licensed major purchases and often bundled with Laravel upgrades, the review cost lands on the platform-upgrade critical path. Disable automated dependency updates for this package in any form; there is nothing to update to.

Support: None. No maintainer response, no security disclosure process, no LTS commitment, no issue triage. If the package sits in an admin surface touching customer or regulated data, its authorization behaviour on attach must be independently verified — a Nova field that bypasses policies is an audit finding, not a bug. The commercial support relationship we have with Nova's vendor does not extend to third-party field code, and their support will reasonably decline to help debug it.

Scaling: Runtime overhead is negligible — Nova admin panels are low-concurrency, and the field only activates when a resource form loads. The one real scaling concern is the searchable selection: if candidate loading is unbounded or unpaginated, a morph table with tens of thousands of rows will produce slow form loads and memory pressure in the admin UI. Verify the search path against production-sized data during the spike, not with fixtures. Organisational scaling is the sharper constraint: a frozen dependency becomes a coordination problem the moment two teams build Nova resources on it and one wants to change behaviour — there is no maintainer to arbitrate, so internal ownership must be named.

Failure modes:

• Silent Nova-upgrade breakage — the field stops attaching or detaching after a Nova major, with no error and no upstream fix. Mitigate by forking and adding a smoke test on the attach/detach path that runs against the Nova upgrade branch.
• Create-form attach no-op — attaching to a parent that does not yet have an ID quietly discards the selection, so admins believe they saved relations they did not. Verify explicitly; this is the most likely correctness defect in any many-to-one Nova field.
• Authorization bypass — the field attaches records the user's policies forbid, creating a compliance exposure invisible in normal QA.
• Unbounded searchable query — admin form load degrades as the morph table grows; discovered by users, not monitoring.
• Abandonment mid-incident — a production issue occurs and there is no one to ask. Mitigate by forking now, while the code is healthy and the maintainer's intent is fresh.
• Schema assumption mismatch — if the Eloquent half expects specific polymorphic column layouts, integration forces migration work that was scoped as zero.
• Phantom dependency — the package is treated as "supported by the vendor" because it lives in the Nova ecosystem; it is not.

Ramp-up: Low for engineering — a Laravel/Nova developer reads this codebase in an afternoon and is productive in hours. The non-obvious ramp-up is governance, and it is the actual TPM deliverable here: name an owner for the fork, define the pinning policy, put the Nova-major re-validation on the platform calendar, and document the morphMany relation contract the field depends on. Left unassigned, this is precisely the kind of quiet responsibility rediscovered during an upgrade freeze. Given the archival status, 2 stars, 0 dependents, and a 0.155 score, the correct default posture is reference implementation, not dependency — adopt the code, not the package.