dillingham/nova-errors
Laravel Nova integration for capturing and managing application errors. Log exceptions to your database and browse, filter, and inspect them right inside Nova—a self-hosted error tracking dashboard for faster debugging, with no third-party service required.
Architecture fit. dillingham/nova-errors is a Laravel Nova extension rather than a general Laravel package. Its scope is narrow and presentation-layer: it injects a Vue component into the Nova admin SPA that renders form validation errors in a summary block above the form fields, instead of relying solely on Nova's inline, per-field error messaging. Architecturally that means three touchpoints: a Laravel service provider registering Nova scripts/styles, a compiled Vue asset bundle, and a dependency on Nova's internal client-side state (the form/error store that Nova populates when a 422 validation response returns). The server-side surface is effectively zero — no migrations, no routes of its own, no model or policy changes — which keeps blast radius small, but it also means the package's entire value sits on undocumented Nova frontend internals.
Integration feasibility. Mechanically trivial: composer require dillingham/nova-errors, register the provider, done. Practically constrained: any Nova extension carries an implicit hard dependency on a paid, closed-source product (Nova licenses are per-site and not CI-friendly without seat planning), and this package is pinned to the Nova 2.x / Laravel 5.5–5.8 / Vue 2 era. We should expect its composer.json constraints to conflict with Laravel 9+/Nova 4+, requiring --ignore-platform-reqs or a fork. With zero dependents on Packagist, there is no ecosystem signal that it installs cleanly anywhere.
Technical risk. High relative to the value delivered. Three compounding factors: (1) the package is unmaintained — last release July 2019; (2) its core capability has been absorbed into Nova itself, which now surfaces validation errors in a top-of-form summary, making the package functionally redundant on any supported Nova version; (3) it depends on Nova's private Vuex/form internals, which are explicitly not covered by semver, so a Nova point release can silently break it with no upstream fix coming. Stars (14) and an opportunity score of 19.45 corroborate that this never reached meaningful adoption.
Key questions.
Stack fit. Compatible only with a legacy slice: Nova 2.x on Laravel 5.8/6.x with Vue 2 and Laravel Mix. If our admin runs Nova 4.x or 5.x, the package does not fit — the correct answer is to use the framework's built-in error presentation and not integrate at all. If our stack is not Nova, the package is irrelevant regardless of version.
Migration path. Recommended path is no migration: treat this as a pattern reference, not a dependency. Read the Vue component (likely a few dozen lines reading Nova's error store), reimplement the equivalent as an in-house Nova custom tool or a small card if the UX gap genuinely exists, and keep the code inside our repo where it can be maintained. Only if we are pinned to Nova 2 with no upgrade window should we consider vendoring a fork: copy the service provider and asset source, replace the Composer dependency with a local path repository, and pin the fork to our Nova version.
Compatibility. Validate before committing: exact composer.json constraints versus our PHP version, laravel/nova constraint, and laravel/framework constraint; whether the published dist/ assets are pre-built (avoiding a Node/Vue-2 toolchain in our build) or require a Mix build; and whether the provider auto-discovers or must be added manually to config/app.php. Assume the assets are stale and may need rebuilding against our Nova version's asset pipeline.
Sequencing. (1) Confirm Nova version and whether native top-of-form errors already close the gap — this alone may end the evaluation. (2) If a gap remains, prototype the summary component in a dev Nova instance for one form to measure real UX lift. (3) Decide build-vs-fork; if fork, add the local package, a smoke test on one resource's create/update forms, and a documented owner. (4) Roll out behind our standard Nova deploy, with a rollback that is simply removing the provider registration — the low-coupling architecture makes reversal cheap, which is the package's main operational virtue.
Maintenance. Effectively zero upstream maintenance: single maintainer, no release since 2019, no dependents to surface breakage. Every future Nova upgrade becomes our regression test. Mitigate by owning the code (fork or reimplement) and documenting it as internal, or by avoiding the dependency entirely.
Support. No vendor, no SLA, no security response channel. MIT license means we can patch, but we carry the burden of noticing breakage — and breakage will appear as a silently missing error summary, not an exception, which is the worst failure signature for a UX affordance. Add a manual check to our Nova upgrade checklist.
Scaling. Negligible runtime cost — it is a client-side render of data Nova already fetched on a 422 response. No server load, no query impact, no per-request overhead. Scaling concerns are organizational, not technical: the number of Nova forms and resource types the component must behave across, and the number of environments where we must validate it after each Nova bump.
Failure modes. (a) Nova upgrades rename or restructure the error store → summary renders empty or the script throws inside the SPA, potentially degrading the whole form panel; (b) stale pre-built assets incompatible with the current Nova asset pipeline → 404s or console errors; (c) duplicate error display if Nova's native summary is also active → visual noise and user confusion; (d) Composer resolution failures on modern PHP/Laravel blocking unrelated dependency upgrades; (e) bus-factor risk from an unmaintained third-party asset loaded into an authenticated admin surface.
Ramp-up. Very low for any Laravel developer — an hour to read the provider and component. The real ramp-up cost is contextual: understanding Nova's private form/error state well enough to port or fix the component, which is not documented and must be reverse-engineered from the Nova distribution. Budget half a day for a confident fork-and-own decision, and treat ongoing ownership as a small but permanent tax against every Nova upgrade. Bottom line for the roadmap: do not adopt as a dependency; harvest the idea, verify Nova's native behavior first, and only build if the UX gap is measurable.
How can I help you explore Laravel packages today?