everestmx/nova-belongs-to-many-field
A Laravel Nova field that adds support for editing belongsToMany relationships directly in Nova resources. It provides a select-based interface for attaching and detaching related models, simplifying many-to-many relationship management in your admin panel.
Architecture fit. The package is a presentation-layer extension for Laravel Nova: it registers a custom field via Nova::script() / a compiled Vue component and maps to an Eloquent BelongsToMany relation. It sits at the outermost edge of the stack — no service-provider side effects on the domain layer, no migrations, no schema changes — so the blast radius of adoption is small and reversible. The important architectural caveat is overlap: Nova has shipped a first-class BelongsToMany field since v2, so this package is only justified if it offers a materially different UX (e.g., inline multi-select or chip input on an index/form rather than the standard detail-screen relationship panel). If it is merely an older realization of native behavior, we are adding a dependency for no functional gain.
Integration feasibility. Mechanically trivial — composer require everestmx/nova-belongs-to-many-field, then reference the field class in the target NovaServiceProvider::fields() or resource fields() method. The real feasibility question is version alignment: Nova 4 moved to Inertia/Vue 3 and changed several field-extension conventions, so a package authored against Nova 2/3 is likely to fail at asset compilation or at runtime with a blank/erroring field. Feasibility is therefore "one afternoon to prove, unbounded to fix."
Technical risk: high. Zero stars and zero dependents is the dominant signal here. There is no downstream cohort validating it against real Nova upgrades, no issue traffic to mine for known defects, and no observable community to inherit maintenance. Specific risks:
composer.json version bounds are the only guardrail.dist/js/field.js. That is third-party JavaScript executing inside an authenticated admin panel — we must review or rebuild it before shipping.allowDuplicateRelations, relatableQueryUsing search hooks, pagination for large relation sets, readonly/nullable, and Nova's dependsOn/rules contracts. Missing any of these means custom work anyway.Key questions to put to the maintainer or resolve by inspection: which Nova major versions are declared and tested; PHP and Laravel version bounds; license; whether dist/ is reproducible from source in the repo; whether pivot attributes and duplicate relations are supported; what happens on sync when the field is partially loaded or read-only; whether the field's query is paginated or eager-loads the full related set; and whether there are any tests, CI, or a changelog at all.
Stack fit. Safe from a framework standpoint — no impact on routing, queues, auth, or persistence beyond the pivot table the relation already owns. It is only appropriate for an application already committed to Nova; it has no value outside that admin surface.
Migration path. Two directions, both cheap. Inbound: if we currently use Nova's native BelongsToMany field and only want a different editing affordance, swapping one field class in a resource is a single-line change and equally reversible, which makes an A/B in a staging environment low-cost. Outbound: if the package disappoints, reverting to native is the same one-line change, though any UX expectations set with product/users would need resetting. There is no data migration in either direction, because the underlying pivot schema is unchanged.
Compatibility. Pin the exact version in composer.json and record the Nova/PHP/Laravel matrix we validated against. Because the package cannot be relied on to publish semver-safe bounds, we should treat any Nova upgrade as a breaking change for this field and include it in the upgrade checklist. If the code is small and the license permissive, the preferred long-term posture is to fork it into our own namespace or a private VCS repository, rebuild the assets from source, and own it — this converts an unmaintained external dependency into a small internal one with a known surface.
Sequencing. (1) Inspect the repository: license, last commit, declared version bounds, source vs. committed dist/, presence of tests. (2) Spike in a disposable branch against our exact Nova version; verify render, search, attach/detach, pivot-field round-trip, read-only mode, and validation error display. (3) Security review of any bundled JS, or rebuild from source. (4) Ship behind a per-resource rollout so a single resource exercises it before broader use. (5) Add a regression test that asserts pivot rows survive an unrelated field edit. If step 1 or 2 fails, stop — the native field is almost certainly adequate.
Maintenance. Effectively zero upstream maintenance and therefore all of it ours. Budget a small but permanent ownership cost: a named engineer responsible for the fork, a rebuild path for the Vue assets, and a note in the Nova upgrade runbook. This is not a package you install and forget.
Support. No vendor, no meaningful issue tracker activity, no community to escalate to. Internal triage is the only channel; a bug in the field is a bug we fix. Against a team already fluent in Nova field authoring this is acceptable for a small UI concern; for a team without that skill it is a standing liability.
Scaling. Two axes. Cardinality: if the field loads the entire related set client-side, resources with thousands of related rows will produce slow renders and oversized payloads — confirm whether it uses Nova's search/pagination endpoints or a full eager load. Concurrency: attach/detach on save is last-write-wins with no locking; two editors on the same record can clobber each other's pivot changes, same as native Nova, so this is an inherited limitation rather than a new one, but it should be documented.
Failure modes. Ranked: (1) a Nova upgrade silently breaks the field — worst case it renders empty and a save detaches all relations; mitigate with the pin, the fork, and the regression test above. (2) Loss of pivot column values on sync. (3) Unescaped related-model labels rendered into the component (XSS in an admin-only context, still worth checking). (4) Asset pipeline failure on deploy if dist/ and source drift. (5) Composer resolution conflicts on a future Laravel/PHP bump with no upstream fix.
Ramp-up. Near-zero for a developer who has written or customized a Nova field — the patterns are conventional and the codebase is presumably a few files. The genuine ramp-up cost is not learning the package but establishing the ownership scaffolding around it: fork, build, test, and document. Recommendation: do not adopt as a live dependency unless the spike reveals a UI capability native Nova genuinely lacks; if it does, adopt only as a vendored fork with the regression test in place.
How can I help you explore Laravel packages today?