Nova Package Bundler Command Laravel Package

Technical Evaluation

Architecture fit. The package is a dev-time Artisan command, not a runtime library. It registers no middleware, no service provider hooks into the request lifecycle, and touches no schema — its only side effects are filesystem writes. That makes it architecturally adjacent to, not entangled with, the Nova asset pipeline: Nova::script() / Nova::style() registration in NovaServiceProvider remains the source of truth for what loads, and this command (potentially) changes the files those calls point at. It is only meaningful in a project with laravel/nova installed; in any other Laravel app it is dead weight. The critical caveat is that the supplied sources describe two materially different tools — one that merges third-party package assets into a single file for faster Nova boot (runtime performance play) and one that scans a package directory and emits a Composer-ready distributable (build/packaging play). Those have different owners, different success metrics, and different blast radii. Architectural fit cannot be signed off until a staging run disambiguates them.

Integration feasibility. Low effort. composer require --dev fidum/nova-package-bundler-command, then php artisan list nova to confirm the command registers and php artisan nova:bundler --help to read the authoritative signature for the installed version. No migrations, no published config required to start, no credentials, no external services. Realistic path to a first validated result on staging: half a day for an engineer fluent in Laravel, most of which is spent reading vendor/fidum/nova-package-bundler-command/src/ (one small command class) rather than integrating.

Technical risk. Ranked by what would actually bite us:

Key questions to answer before commitment.

1. Which mode is it — asset consolidation, source vendoring, or scaffolding? Answered by --help plus one staging run, not by the README.
2. Do we publish Nova packages internally (Satis / private Packagist), or only consume third-party ones? The packaging use case is moot if we never ship packages.
3. How many Nova packages are actually installed today? The runtime benefit scales with count — with two tools, the delta is noise.
4. What is the pain we are buying down: Nova admin load time, or release engineering time? Different justification, different metric.
5. Who is the named owner in the dependency register, and can we remove this in one PR with zero application-code changes?

Integration Approach

Stack fit. Laravel + Nova + Composer, PHP 8.x. require-dev only, in every scenario. For the package-author pattern it belongs in the package repo's require-dev; the consuming application should never need it because it receives compiled files via Composer. Node is only relevant if the command turns out to be build-mode rather than consolidation-mode.

Migration path. Baseline → pilot → widen, never the reverse.

1. Capture the before-state on staging with the real set of Nova tools installed: count of JS/CSS requests on the Nova admin surface and a load timing; or, if build-mode, current release duration.
2. Install on a throwaway branch and run against a single existing Nova tool or card.
3. git status --short and git diff before committing anything — establish whether the output is repeatable build output (must run every build, gitignore-able) or a scaffold we now own (commit once, never re-run).
4. Wire one invocation into the deploy/build script ahead of the asset publish step.
5. Widen to all packages only after the pilot produces a number.

Compatibility. Pin ^1.8.1 and treat Nova's compatibility as the gate, not Laravel's. Verify the installed laravel/nova version is exercised on the same framework major before scheduling any framework bump. Validate on a staging Nova surface, not locally — nova:publish behaviour differs between environments and is the most common source of path mismatch.

Sequencing.

• Week 0: disambiguation run + baseline capture (owned by one engineer).
• Week 1: pilot on one package, single-line script entry, revert instructions written into the PR description.
• Week 2: CI guard — php artisan nova:bundler in the build job followed by git diff --exit-code -- '*.js' '*.css' only if output is committed; drop the guard if output is generated fresh per deploy.
• Post-pilot: decision gate — widen, or remove. Do not leave it half-integrated.

Operational Impact

Maintenance. Treat as best-effort, single-maintainer upstream. It needs a named owner in the dependency register and Dependabot/renovate coverage. If the command scaffolds artifacts we then own, budget roughly half a day per Laravel major to hand-edit the snapshotted constraints in those artifacts, plus review time — that cost does not inherit from bumping the package itself. The 1.8.1 Laravel 13 allowance removes one line item from the upgrade backlog but is a constraint change, not a capability.

Support. No vendor SLA, no dependents to lean on for war stories, thin extension points. Mitigation is structural, not contractual: one dependency line, one invocation line, one clear rollback. Because it sits outside the request lifecycle and writes only files, removal is a single PR with zero application-code changes — that reversibility is the main reason to trial it opportunistically rather than run a procurement cycle.

Scaling. Value scales with the number of Nova packages installed, not with traffic or user count. Cost scales with release frequency: every Nova tool version change is a re-bundle. CI cost is negligible (one Artisan invocation). The one thing that scales badly is the failure to standardise early — retrofitting a bundling convention across a growing Nova portfolio costs more than adopting it at two packages.

Failure modes to instrument for.

• Stale bundle after a tool upgrade — UI renders but a component is inert, or a "component not registered" console error. Almost always drift, not compilation. Fix is re-run; prevention is the CI git diff --exit-code guard.
• Path mismatch after nova:publish — 404s in the network panel on the bundle path. Standard remedy: config:clear, view:clear, nova:publish --force.
• Merge ordering collision — two tools registering Vue components into one file. Revert the offending tool to per-package registration rather than debugging the merge.
• Generator overwrite — re-running over hand-edited scaffold output. Never re-run a generator over an artifact you own.
• Cache staleness — stable output path served from browser or Nova cache; stamp a version into the filename or bump an app-version constant at registration time.

Ramp-up. Minutes for a Laravel-fluent engineer to run it, a half-day to understand it. The real ramp-up cost is organisational: someone must own the decision on whether dist/ is committed or gitignored, and write it down. A repo that half-commits compiled assets is worse than either policy, and that inconsistency — not the package — is what generates merge conflicts and on-call confusion.

Justification discipline. "Improves Nova initial load speeds" is testable; record request count and load timing before and after on the surface we actually run. If the delta is in the noise at our package count, keep the dependency only if it demonstrably cuts release time — otherwise remove it and record why. Keep the whole line item in the engineering budget, not the product scorecard.