Nova Devtool Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. Nova is Laravel's first-party, paid admin panel. This package lowers the marginal cost of building custom Nova components (cards, fields, resource tools, metrics) by removing the "spin up a host app to see your component" tax. If your team already pays for Nova, this is the piece that makes owning custom components economically rational versus buying more third-party Nova packages.
• Roadmap: an internal, reusable Nova component library. Everything here is oriented around packaging components as standalone Composer/NPM packages developed inside an Orchestra Workbench workbench directory — i.e., isolated, versioned, testable, releasable. That is a prerequisite for a "build once, reuse across apps" strategy rather than copy-pasted admin code.
• Standardization decision. The generic nova.mix.js (mix.extend('nova', new require('laravel-nova-devtool'))) replaces per-component boilerplate. Adopting it is a decision to have one frontend build convention across all Nova components instead of N bespoke webpack configs, which directly reduces maintenance surface and review friction.
• Upgrade planning. The release history is almost entirely "Supports Laravel Nova 5.x" patches (5.1 → 5.11) plus Laravel 12/13 support. This tells you Nova upgrades are a routine devtool bump, not a re-tooling project — useful when deciding how aggressively to track Nova releases.
• Estimation and onboarding inputs. Workbench setup, auto-login via testbench.yaml, one-command Axios/Lodash/Tailwind/Vue install, and Vue DevTool enable/disable are concrete, measurable reductions in time-to-first-working-component and in the Nova-specific frontend knowledge a new engineer needs.
• Debugging capability you otherwise don't have. Nova ships production-compiled JS with no Vue DevTools; enable-vue-devtool / disable-vue-devtool toggles that. This is a real dev-loop productivity lever, not cosmetic.
• Nova 4 → 5 migration path. The documented mix.extend('nova', ...) change and removal of per-package nova.mix.js is a scoped, low-risk migration task you can slot into a sprint rather than treat as an unknown.

When to Consider This Package

Adopt when:

• You build or maintain two or more Nova custom components, or ship a private Nova package consumed by multiple apps.
• Your current Nova dev loop requires a full host app, manual seeding, and manual login on every iteration — that repetition is the value being removed.
• You want consistent build config across several Nova packages, or you're cleaning up Nova 4-era per-package nova.mix.js files.
• You're on supported Nova 5.x and accept lockstep upgrades (this package releases specifically to track Nova point versions — plan the devtool bump as part of every Nova bump).
• laravel-mix/webpack is acceptable on your frontend toolchain.

Look elsewhere / deprioritize when:

• You have a single, small, throwaway Nova customization — workbench setup overhead exceeds the payoff.
• You only configure Nova resources and don't author custom components — near-zero value.
• You're not on Nova at all (Filament, custom Livewire, bespoke admin) — not applicable.
• You need a test harness (unit/browser/CI coverage) — this is local developer experience tooling, not a testing framework; pair it with Pest/Dusk/Playwright.
• Your org mandates Vite-only frontends — this is a webpack/laravel-mix toolchain; you'd be carrying dual tooling.
• You require vendor SLA, community support, or extensive third-party documentation. Signals here: 33 stars, no notable external dependents, docs limited to the README, effectively a single-maintainer cadence. It is first-party Laravel org maintained, which mitigates abandonment risk, but not docs/support risk.

Adoption note for the record: the "0 dependents" figure should not be read as a red flag — this is a --dev dependency plus an NPM dev dependency, a category that dependent-counting systematically undercounts. The more meaningful signal is that releases are frequent, small, and tightly coupled to Nova releases, which is exactly what you want from a compatibility shim and exactly why you should not fork or pin it for long.

How to Pitch It (Stakeholders)

For executives: A free, official Laravel-org development-only tool for teams that build custom components inside Nova, the admin panel we already license. It carries zero production runtime risk — it is installed as a dev dependency and never ships. The ask is small: one Composer dev dependency plus one NPM dev dependency. The return is reduced engineering time on every custom Nova component we build, a single standardized frontend build configuration instead of per-component snowflakes, working Vue DevTools against Nova's production-compiled assets (debugging capability we currently lack), and a documented path off Nova 4-era build boilerplate. It's a productivity multiplier on work we're already doing, not a new capability we have to staff.

For engineering: It bootstraps a full isolated Nova installation in a workbench directory via Orchestra Workbench (testbench nova:devtool setup), with optional auto-login through testbench.yaml, so you composer run serve and iterate on a component without a host app. nova:devtool install wires up Axios, Lodash, Tailwind, and Vue; enable-vue-devtool / disable-vue-devtool toggle DevTools support against Nova's production bundle; a shared nova.mix.js replaces copy-pasted build config across packages. Migration from Nova 4 is a two-line webpack.mix.js change. Caveats to internalize: it's webpack/laravel-mix, not Vite; it's version-locked to Nova point releases, so treat "bump Nova" and "bump devtool" as one task; and documentation lives almost entirely in the README, so budget a short internal wiki page and a working example component as part of the pilot.

Recommended next step: pilot on the next internal Nova component. Success metrics: time from git init to a working component in a browser, setup steps per new package (target: one command), and effort to track the next Nova point release.