Nova Package Bundler Command Laravel Package

Product Decisions This Supports

• Build vs. buy for internal Nova tooling — framed as cost-per-release, not capability. The alternative isn't "no bundling," it's a hand-maintained composer.json plus per-package Mix/Vite wiring, owned by whoever cuts Nova releases. A hand-rolled setup is genuinely competitive for one or two extensions; the buy case strengthens with volume and repetition. Decide on release-time economics, not on features — the package's feature list is thin and that's fine, because the feature isn't the product, the saved release ritual is.
• Roadmap sequencing for the admin/back-office surface. This is a dev-time build command outside the request lifecycle, so it should never compete for a customer-facing roadmap slot. But it does gate when Nova work ships. The real decision is sequencing: standardise how we publish Nova tools/cards before the portfolio grows, or retrofit later. Retrofit cost scales with the number of packages, not with usage, so standardising early is the cheaper path — and that's a decision a PM can make now with low commitment.
• Laravel 13 upgrade planning — a de-risking input, not a green light. Release 1.8.1 widens the framework constraint for Laravel 13 as a patch release: no breaking change, no migration. That strikes one line off the upgrade backlog. It does not clear the upgrade. Nova's own Laravel 13 compatibility is the actual gate and must be tracked as its own roadmap dependency. Do not let "the bundler supports 13" leak into a stakeholder update as "we support 13."
• Dependency register and maintenance-health tracking. Record two facts side by side and act on both: a positive compatibility signal (same-cycle major bump, active 1.x line with external PRs) and a real bus-factor risk (single maintainer, 0 dependents, ~21 stars). This belongs on the "track with a named owner" list, not the "set and forget" list. The low star count is not disqualifying for a dev-only, single-command tool — but it does mean we assume best-effort upstream and plan for ownership.
• Blast-radius scoping as a decision input. Because it lives in require-dev and never touches the request lifecycle, it can be removed in a single PR with zero application-code changes. That low reversibility cost is itself the argument for an opportunistic trial on staging rather than a procurement cycle. If the command turns out to scaffold files we then own, that calculus changes — the exit becomes "we own this now," which is worth knowing before, not after.
• Release-engineering process ownership. This answers "how do we cut a Nova package release?" — relevant only if we publish Nova packages internally (Satis / private Packagist) or ship them to client apps. If we only consume third-party Nova packages, the decision is largely moot and should be closed, not parked.
• Primary use cases to evaluate against: (a) we author Nova tools/fields/cards and want one bundling step instead of per-package build config; (b) we run many third-party Nova packages and want to reduce admin initial-load requests; (c) we want a repeatable, scriptable post-composer update asset step. These have different success metrics and different owners.

One caveat that must be resolved before any of the above becomes roadmap language: our sources disagree on what the command actually does — merge third-party package assets into one bundle (runtime load-speed play), compile a package's own frontend source into distributable output (build-convenience play), or scaffold a Composer-ready metapackage. These imply different success metrics (requests and load timing vs. release hours saved), different owners (platform/ops vs. package maintainers), and different failure modes. A single staging run plus a read of vendor/fidum/nova-package-bundler-command/src/ settles it in under an hour. Do not commit to a metric until it's settled.

When to Consider This Package

Adopt when most of these are true:

• You are on Laravel Nova and will stay on it — the package is meaningless without NovaL.
• You either maintain Nova packages in-house or run a meaningful number of third-party Nova packages. Value scales with package count, not traffic; one installed tool will show you nothing measurable.
• You cut Nova releases often enough that per-package build wiring is a recurring tax. If you ship a Nova package once a quarter, hand-roll it.
• You have a staging or scratch environment where you can run an Artisan command that touches files, plus a git diff habit and a revert in the PR description.
• You're willing to own the dependency structurally: require-dev only, one invocation line in one script, a named maintainer, and a documented exit path.
• You have a baseline. Capture Nova admin load timing and JS/CSS request counts before running it, or you will have no way to justify keeping it or removing it later.

Look elsewhere (or don't bother) when:

• Nova isn't in the stack, or there's an active plan to move off it. This is Nova-shaped tooling; the investment doesn't transfer.
• You have one or two Nova packages and no internal package-publishing pipeline. A hand-maintained composer.json and per-package Mix/Vite config is competitive and has fewer unknowns.
• You need vendor support, SLAs, or a roadmap commitment. Single maintainer, no dependents, ~21 stars, best-effort upstream. If your release process cannot tolerate an unmaintained dev dependency, this fails the bar regardless of how good the command is.
• Your justification hinges on admin load speed and you can't instrument it. "Improves Nova initial load speeds" is a testable claim — if you can't measure it on the realistic set of tools you run, you don't have a case, you have a README quote.
• You're mid-Laravel-major upgrade and would be adopting this while also moving Nova. Sequence those separately; conflating them makes the rollback ambiguous.
• Your team leans on generated code being treated as owned code. If the command scaffolds rather than builds, re-running it over an edited artifact produces overwrite-or-merge surprises. That's a workflow constraint not every team wants.

Adoption shape, if you proceed: put it in the package repo's require-dev only, not the consuming application's composer.json — consumers should receive compiled files via Composer and never need Node. Commit compiled dist/ for packages we distribute; gitignore it for private apps that rebuild on deploy. Pick one per repo and write it down; a half-committed dist/ is worse than either.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small Laravel developer tooling dependency, not a product feature. It's worth a narrow trial because it can standardise how we build and ship Laravel Nova admin extensions, which today is bespoke work per package. The upside is engineering time saved per release and potentially a faster-loading admin; the downside is bounded — it installs as a dev-only dependency, never runs in production requests, and can be removed in a single pull request without touching application code. It carries maintenance risk (essentially one maintainer, negligible adoption), which is why the recommendation is a staging trial with a named owner and a measured baseline, not a procurement cycle or a roadmap commitment. Do not book any customer-facing benefit against it.

For engineering — the substantive summary: fidum/nova-package-bundler-command is a single Artisan command, MIT, require-dev only, currently 1.8.1 with Laravel 13 allowed as a patch-level constraint widening. It either consolidates third-party Nova package assets into one file (runtime request-count play) or bundles a Nova package's own JS/CSS into distributable output (build-convenience play) — the sources conflict and the --help output plus src/ resolves it in minutes. Start on a throwaway branch against one real Nova tool, run git status --short and git diff before committing anything, and capture Nova admin request counts and load timings against a pre-change baseline on a surface with our actual tool set installed. If it's a build step, wire it into the build job (not the test job), optionally guard with git diff --exit-code on compiled assets to catch re-bundle drift, and keep asset registration in NovaServiceProvider — the bundler owns file contents, Nova owns registration, don't conflate them. Known failure modes to watch: stale consolidated bundles after a tool version bump, load-order collisions between packages, and path mismatches after nova:publish. Revert path is a single PR.

Ask: approve a time-boxed staging evaluation (roughly a day of engineering plus review), with a named owner and one written conclusion — adopt, adopt-with-conditions, or close. The output we want isn't "it works"; it's a measured number and a documented exit path.