Nova Errors Laravel Package

Getting Started

Install

composer require dillingham/nova-errors

Before you commit, check what it resolved against:

composer show dillingham/nova-errors

The last tagged release is from mid‑2019, so it was built against the Nova 2.x era (Vue 2, laravel-mix, nova.mix.js). If you are on Nova 3/4, confirm the constraints and the compiled JS actually load before you wire it into every resource.

Where to look first

1. src/ — the NovaErrors field class; this is what you register in fields().
2. resources/js/ — the Vue component that renders the error list. This is the piece that has to talk to Nova's error store, and it is the piece most likely to break across Nova majors.
3. README.md — for the exact make() signature and any ->withMeta() options.
4. composer.json / package.json — the Nova and Vue version constraints, i.e. your compatibility answer.

First use case

The package exists for one reason: Nova shows validation errors inline, next to the field. On a long form (30+ fields, tabs, or a Panels/Fields layout) the failing field is often below the fold, so the user hits Save, sees nothing change, and assumes the button is broken. This package surfaces the full validation error list at the top of the form.

The minimal wiring is a field in your resource:

use Dillingham\NovaErrors\NovaErrors;

public function fields(Request $request)
{
    return [
        NovaErrors::make(),   // keep it first
        ID::make()->sortable(),
        Text::make('Name')->rules('required'),
        // ...
    ];
}

Submit an invalid form and you should see the aggregated messages at the top. That single test tells you whether the JS asset, the error store binding, and the field registration all work on your Nova version.

Implementation Patterns

Register it once, not per resource. Add the field to a base resource class and let every resource extend it:

abstract class BaseResource extends Resource
{
    public function fields(Request $request)
    {
        return array_merge(
            [NovaErrors::make()->onlyOnForms()],
            $this->resourceFields($request)
        );
    }

    abstract protected function resourceFields(Request $request): array;
}

Then fields() in each concrete resource returns $this->resourceFields($request) entries. New resources get the error banner for free, and you have one place to remove it if the package rots.

First in the array is what matters. Nova renders fields in declaration order; anything after a Panel or a Field::make(...) block will land below it visually. If you can't control ordering because a resource builds fields dynamically, prepend explicitly rather than trusting merge order.

Form-only, never persisted. This is a display-only field with no backing column. Guard against Nova trying to fill/save it:

NovaErrors::make()->onlyOnForms()

onlyOnForms() keeps it off index/detail views (where there is no error bag anyway). If your Nova version still attempts to resolve the attribute, also give it a name you never validate against and make sure it is not in $fillable semantics for the resource.

Pair it with the rules it is reporting. The banner is only as good as your validation. Keep rules on the resource (->rules('required', 'max:255')) or in a rules(Request $request) method, and keep custom messages in resources/lang/{locale}/validation.php. The package is not a validator — it renders whatever Laravel's validator put in the session error bag.

Long or tabbed forms are the sweet spot. On a Tabs/Panels layout, the top-of-form banner tells the user which tab holds the problem, because validation messages are prefixed with the attribute label:

The billing address city field is required.

That sentence is worth more than a red border on a hidden panel.

Complement, don't replace, inline errors. Keep Nova's per-field errors on. The banner answers "did my submit fail and why"; the inline error answers "fix this box". Removing inline errors to avoid duplication is a net loss.

Tooling/action contexts. Because it is a Nova field, it needs a form context to mount. Field-based components do not automatically appear inside action modals or custom tools unless those contexts also render resource fields. Treat this as a resource-form feature and don't plan on it for action validation UX without testing.

Testing. The behaviour you care about is "submit invalid, see text". That's a Dusk/browser test, not a unit test:

$browser->visit('/nova/resources/users/new')
        ->type('name', '')
        ->click('Create User')
        ->waitForText('The name field is required.');

Gotchas and Tips

Compatibility is the real risk. 2019 release, 14 stars, no dependents. That is a signal, not a verdict — but budget for it. Read composer.json for the nova constraint and package.json for vue. A Nova major upgrade that moves Vue 3 / Vite will silently leave you with a component that never renders. Test the banner specifically after every Nova upgrade, not just "the app boots".

Assets are compiled, not built at install. Nova field packages ship a dist/js bundle. If the banner is absent and the field shows nothing (or an empty div), the asset is the first suspect: confirm the service provider calls nova-assets/Nova::script(...) correctly for your Nova version, and clear caches:

php artisan nova:publish
php artisan view:clear

It only shows validation (422) errors. A 500, a policy denial, or a custom Nova::error() toast will not appear here. If you need exception messages surfaced, that is a different mechanism (toasts / Nova::error()), and mixing expectations leads to "the banner doesn't work" bug reports that aren't bugs.

Error keys are dotted. Nested attributes (address.city, items.0.qty) arrive as dotted keys. If the component flattens or formats them, verify nested arrays render readably — that is where a 2019 component tends to fall over on modern forms with HasMany/KeyValue fields.

Don't add it to index/detail. On non-form views the field either renders empty chrome or interferes with the table layout. Always ->onlyOnForms().

Localisation mismatch. Error text comes from your app's validation.php, but any labels the component renders itself may be hardcoded English. If you ship a non-English admin, vendor the component and translate, or accept the mix.

Vendor it if you depend on it. With no maintainer activity since 2019, the pragmatic move on a production Nova app is to copy the field class and component into nova-components/ or your app's Nova namespace and own it. The functionality is small — an error list reading Nova's error store plus a field wrapper — so forking costs an afternoon and removes the dependency risk entirely.

Extension point: your own banner. If you fork, the useful additions are (a) collapse/expand for very long error lists, (b) anchor links that jump to the offending field, and (c) suppression of duplicate messages when the same rule fires on many rows of a HasMany. Those three turn a novelty into something users actually rely on.

Fallback if it breaks. Nova's built-in per-field errors already work; the banner is a UX improvement, not a correctness fix. Ship it behind a base-resource flag (if (config('nova.error_banner'))) so you can turn it off per environment or per resource without deleting code.