Asset Bundle Laravel Package

Technical Evaluation

Architecture fit The package advertises a config-file bundle definition plus Blade directives — i.e., its own asset-resolution abstraction layered on top of Laravel. That is the architectural crux. Laravel has converged on a manifest contract (Vite build → manifest.json → Vite::asset()), and third-party asset tooling either honors that contract or competes with it. A Blade-directive API strongly suggests a parallel resolution path: a second source of truth for where hashed assets live and how they're named. For a TPM this is the single most consequential finding, because parallel asset resolution is a permanent tax paid by every future feature that touches URLs, CDN config, or white-labeling. Secondary flag: the -bundle suffix is Symfony naming convention, not Laravel. Treat "Laravel support" as a claim to verify against composer.json and the service provider, not as a given.

Integration feasibility Feasible to evaluate, not feasible to commit on current evidence. MIT removes legal friction; zero stars, zero dependents, and a score of 0 remove all corroboration. There is no community compatibility matrix, no issue history to read as a proxy for version support, and no tutorial corpus. The TPM's move is to convert this from an opinion debate into a bounded experiment: 1–2 days, disposable branch, full source read, explicit acceptance criteria written before the spike begins. Success criteria should be behavioral, not aesthetic — registers via package discovery, resolves assets under php artisan serve and behind a real web server, survives config:cache and route:cache, and produces identical URLs across two consecutive builds.

Technical risk

• Abandonment (high): zero dependents means no fork community absorbs the load if upstream stops.
• Bus factor (high): single-maintainer signature; no visible governance.
• Compatibility drift (high): Laravel's asset story has already taken one hard break (Mix → Vite). A zero-adoption package will not track that cadence by default.
• Opportunity cost (high): this is the risk TPMs most often under-price. Every spike-day is a roadmap-day.
• Security / supply chain (medium): asset pipelines write to public/, publish files, and sometimes fetch remotely. Pin to a commit SHA; never a floating constraint.
• Duplication (medium): if the stack is already Vite-native, adoption is a net-negative addition of a second mental model.

Key questions Each question should sit in the spike ticket with a named owner and the decision it unblocks:

1. What is the one-sentence capability gap Vite does not close? No sentence, no adoption.
2. Does it consume a Vite manifest, or require its own compile step — and what does that step cost in CI minutes and onboarding?
3. Which Laravel/PHP versions are declared in composer.json (not implied by the README)?
4. Does it write to public/ at runtime, or is it build-time only? Runtime writes are a deployment anti-pattern and a hard blocker in hardened containers.
5. Are output hashes deterministic and content-stable across consecutive builds?
6. Total lines of source we would be agreeing to own, and who fixes it at 2 a.m.?

Integration Approach

Stack fit Narrow, and the fit decision should be written down so it stops being relitigated. Legitimate fit exists only where a named gap lives: a pre-Vite legacy application that still needs manifest-style resolution, a package that must publish versioned assets, or a multi-tenant/white-label theme resolver. If the application is greenfield or already Vite-native, the correct answer is "no" — this package duplicates capability and adds a dependency.

Migration path Additive, never substitutive. Do not move existing Vite-built assets onto it. Scope it to the one asset class it uniquely serves, run both pipelines in parallel behind a config flag, and assert output parity: hashed filenames, cache headers, MIME types, and correct URLs in both local and production. The rollback must be one command — remove the Composer entry and the provider registration — and must be documented before the parallel run starts. If the parallel run yields no measurable win within one sprint, terminate.

Compatibility Pin to an exact version or commit SHA. Add a CI job running the suite against the top and bottom of the declared Laravel/PHP matrix; with no dependents we are the first integration test and should budget accordingly. Critically, add a CI job that executes the full deploy sequence, not just the test suite — service providers that register asset paths at boot are a classic source of production-only failures after config:cache.

Sequencing

1. Spike (1–2 days, disposable branch): install, read the entire source, verify provider registration and asset resolution under serve and a real web server. Deliverable: written findings, not a demo.
2. Gap validation (≤1 day): write the one-sentence justification and the removal estimate in hours. No sentence → stop.
3. Parallel run (one sprint, staging only, behind a flag): measure against the incumbent on build time, cache-hit behavior, and hash stability.
4. Decision gate — adopt / fork-and-vendor / discard. Default is discard. Absent a measured win, discard is the correct, documented outcome.
5. If adopted: vendor into an internal namespace immediately, assign a named internal owner, and write an internal runbook. Fork at adoption time, never after the incident.

Operational Impact

Maintenance This is the dominant cost and the TPM should own it as a line item. A zero-dependents package transfers essentially all maintenance to us — assume we patch it against future Laravel majors. Budget a quarterly dependency-health check: still installs, still passes CI on the current framework version, not archived upstream. "Whoever is on call and can read the source" is a real cost, not a satisfying answer; write it down as such.

Support No meaningful support channel: no triage, no community, no paid tier. Internal support therefore means internal expertise, which means two engineers must have read the source, not one. Do not rely on upstream docs, which may be stale or aspirational — write our own runbook describing observed behavior, not documented intent.

Scaling Asset pipelines scale on two axes: build-time (CI minutes, cache hit rates, artifact size) and edge-time (CDN hit ratio, hash stability). The headline risk is nondeterministic hashing — it silently destroys CDN and browser caches and is invisible in tests. Also validate cold-cache builds and concurrent builds; unvetted output-directory handling frequently races under parallel CI.

Failure modes

• Silent asset 404s, production only (highest severity): mitigate with a post-deploy smoke test that fetches a known hashed asset and asserts 200 plus the expected hash.
• Build-time nondeterminism: mitigate with two consecutive CI builds and a diff assertion.
• config:cache incompatibility: mitigate with a CI job running the full deploy sequence.
• Upstream abandonment: mitigate by forking at adoption, not after breakage.
• Filesystem permission failures: confirm build-time-only operation; runtime writes to public/ are a blocker.

Ramp-up Inversely proportional to documentation quality, and with zero dependents there is no external corpus. Estimate 0.5–1 day for a mid-level engineer if the package is well-documented and narrowly scoped; 2–3 days if the source must be read to understand behavior. Weigh that against the incumbent, whose onboarding cost is effectively zero because it appears in every Laravel tutorial the team has already read. Include ramp-up hours explicitly in the spike estimate — and note that even in the discard case the organization retains value: a reference implementation and a known-failure-mode checklist for the in-house alternative, plus a documented rationale that prevents the same package resurfacing next quarter.