Nova Relationships Link List Laravel Package

Getting Started

This is a single-purpose Nova field: it renders a relationship as an inline, comma-separated list of links to the related Nova resources instead of Nova's default HasMany/BelongsToMany table. The value proposition is simple — compact detail views and fewer clicks — so evaluate it as a UI convenience, not infrastructure.

Minimal setup:

1. composer require brilliant-packages/nova-relationships-link-list
2. If the package ships a service provider, confirm it is auto-discovered in composer.json (extra.laravel.providers). If not, register it in config/app.php.
3. Publish the field assets if the README instructs it (php artisan vendor:publish --provider="BrilliantPackages\NovaRelationshipsLinkList\..." or a tagged publish). Nova field components are JS assets; a missing publish step is the most common "field renders blank" cause.
4. No migrations, no config file, no scheduled jobs.

Where to look first:

• The README example — the exact fluent API (->relationship('tags') vs. inferring from the field name) is the one thing you should not guess.
• src/ for the field class: the $component string tells you what the Vue component expects, and any public properties ($relationship, $displayField, etc.) tell you what is configurable.
• dist/ — if compiled assets are committed, installation is trivial; if not, you will need npm install && npm run prod inside the package.

First use case: a Post detail page with a noisy HasMany "Tags" table. Replace it with:

use BrilliantPackages\NovaRelationshipsLinkList\RelationshipsLinkList;

public function fields(Request $request)
{
    return [
        // ...
        RelationshipsLinkList::make('Tags')
            ->onlyOnDetail(),
    ];
}

The field name typically maps to the relationship method (Tags → tags()). Confirm that mapping before debugging anything else.

Implementation Patterns

Detail-view compaction. The intended pattern is ->onlyOnDetail() alongside ->readonly(). This field is a display affordance; it does not give you form controls for attaching/detaching related models. Keep your BelongsToMany field on the form, and use this on the detail page.

One field per relationship. For resources with several many-to-many links (categories, tags, authors), stack multiple instances rather than trying to configure a composite field. Each instance resolves one relationship.

Eager loading is mandatory if you show it on index. A link list is cheap per model but the relationship is lazy-loaded by default. If you drop ->onlyOnDetail() and show it in the index, add the relationship to indexQuery:

public static function indexQuery(NovaRequest $request, $query)
{
    return $query->with(['tags', 'categories']);
}

Without that, a 50-row index becomes 50+ extra queries per relationship.

Label resolution. These fields almost always derive link text from a conventional attribute (title, name, or Nova's $title). If your related model uses something else (label, slug), check whether the field exposes a display callback; if not, add a Nova title()/subtitle() to the related resource — that is the cleanest fix and benefits the rest of the admin.

Fallbacks. Nullable or empty relationships should render as an em dash or blank. Verify visually; a field that outputs , or an empty anchor is a common rough edge in small packages.

Combination with resolveUsing. If you need to filter which related models appear (e.g., only published tags), prefer a scoped relationship method on the model over fighting the field's resolution logic:

public function publishedTags()
{
    return $this->tags()->where('published', true);
}

Then point the field at Published Tags. This keeps the logic testable outside Nova.

Extension point. Because the field is small, subclassing it or copying it into app/Nova/Fields is a legitimate pattern if you need different link formatting, badges, or a target="_blank" behaviour. At 5 stars and zero dependents, you are not inheriting a large API surface — you are inheriting one file and one Vue component.

Gotchas and Tips

• Maintenance risk is the headline. Five stars, zero dependents, and a low health score mean this is effectively unmaintained for practical purposes. Pin the version in composer.json, and budget an afternoon to verify it against your Nova major version (Nova 4 vs. Nova 5 component APIs differ). If it breaks on upgrade, forking is cheaper than waiting for a fix.
• Field-name-to-relationship inference is the usual failure. Nova fields conventionally StudlyCase the label and snake_case the attribute. If links render empty, explicitly set the relationship (if supported) or rename the field to match the method exactly before assuming the package is broken.
• Blank component = asset problem, not PHP problem. If the field renders as an empty cell, open the browser console. A missing relationships-link-list component means the JS was never published or built. Check dist/ in vendor/.
• Authorization is per-link, not per-field. Nova will happily render links to related resources the current user cannot view; clicking yields a 403 or a missing resource. If that matters, filter the relationship or restrict the field with ->canSee().
• Not a substitute for the relationship table on forms. Do not remove your attach/detach UI expecting this field to handle it. It is read-only by design.
• Large relationship sets truncate or wrap badly. A post with 200 tags produces an unusable wall of links. Cap the relationship query or fall back to the standard table for high-cardinality relationships.
• Debugging checklist, in order: (1) field name matches relationship method, (2) relationship returns models, (3) related Nova resource exists, (4) assets published, (5) browser console clean. Ninety percent of issues are steps 1 or 4.
• Opportunity: with essentially no competition in this niche and no active maintainer, a two-hour internal fork — add a display callback, a link limit, and Nova 5 compatibility — gives you a field you control. Treat the upstream package as reference code rather than a dependency you build on.