Webpack Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow (core decision). This package answers a narrow architecture question: should each Symfony bundle own its own frontend entry points, or should the app have one central webpack.config.js? It enables the "federated assets" model — a bundle ships its own Webpack config fragment, and the app composes them. That's a decision about team ownership boundaries, not just tooling.
• Feature scoping for multi-bundle platforms. If our roadmap includes shipping reusable internal bundles (admin UI, auth, billing widgets) to more than one product, this is the kind of package that makes those bundles genuinely self-contained. That directly affects whether we can treat "bundle" as a real product unit.
• Roadmap sequencing for asset pipeline modernization. Adopting this is a decision to stay on Webpack rather than migrate to Vite/Encore's newer path. It's an explicit "we are not doing an asset-pipeline rewrite this year" commitment — useful as a cheap way to buy 12–18 months before a bigger migration.
• Platform consistency / DX investment. It reduces the "every bundle has a slightly different asset story" tax. Quantify it: onboarding time per new bundle, number of bespoke webpack.config.js files, incident count from asset path/version drift.
• Not a Laravel decision. Despite the brief, this is a Symfony bundle (DI container integration, Bundle class, Symfony config tree). For a Laravel roadmap the equivalent decisions belong to Vite or laravel-mix; treat this as out of scope unless we run Symfony services. Flag this before anyone puts it in a Laravel backlog.
• Opportunity signal. The high opportunity score reflects an under-served niche (bundle-level asset composition). If we have this need repeatedly, the strategic option is a thin internal wrapper we control, not a hard dependency on a 2020-era third-party package. The 1.1.3 patch does not change this calculus: one release is not a maintenance commitment.
• Supply-chain diligence is now a decision input. The 1.1.3 patch is the first upstream release in roughly five years and shipped with empty release notes. That is not evidence of a feature or a revival; it is an unexplained post-dormancy artifact from a single-maintainer project. Whether we trust it is a decision, and it should be made explicitly (diff + provenance check) rather than assumed from a version bump.

When to Consider This Package

Consider it when all of the following hold:

• The codebase is Symfony, on a version line this package actually supports (roughly Symfony 4/5, Webpack 4 era). Verify against our Symfony version before anything else — 1.1.3's release notes are empty, so do not assume the supported Symfony/Webpack matrix has widened.
• We have many bundles that each need their own JS/CSS, and the central Webpack config has become a merge-conflict hotspot.
• We want bundle portability — the same bundle dropped into a second app and its assets "just work."
• The need is internal/back-office tooling, where a stale dependency is annoying rather than customer-facing.
• We've accepted a maintenance subsidy: we're willing to fork, patch, or pin. Upstream activity effectively stopped in January 2020; the 1.1.3 patch is a single, undocumented data point against a five-year gap, and there are still zero dependent packages — no community safety net, no downstream pressure to keep it working.
• New gate: 1.1.3 passes provenance review before adoption. Diff the tag against the last 1.0.x release, confirm the tag is signed/attributable to the historic maintainer, confirm no new install-time or build-time side effects, and prefer pinning to the prior 1.0.x line if 1.1.3 cannot be accounted for. An unexplained release after dormancy is a security-review item, not a reason to upgrade.

Look elsewhere when:

• It's Laravel. Wrong framework entirely; use Vite or laravel-mix.
• We're on Symfony 6/7 or planning to upgrade soon. An unmaintained bundle is a migration blocker, not a migration aid.
• Webpack Encore covers the need. The official Symfony path is the default "buy" answer; only deviate if per-bundle config composition is genuinely the blocker.
• The team's frontend direction is Vite/esbuild. Adding a Webpack-only composition layer now creates work to undo later.
• It's customer-facing or security-adjacent. ~122 stars, a five-year release gap interrupted by one undocumented patch, single maintainer — the bus factor is the risk, not the license (MIT is fine).
• We only have one or two bundles. The composition overhead exceeds the benefit; a shared config module is cheaper.

Decision hygiene: require a written exit plan (how we'd remove it: bundle configs are plain Webpack fragments, so extraction is straightforward — that's the package's main redeeming quality) and a fork-owner named in the ADR. Record which version we pinned and why, and set a re-review trigger on the next upstream release: if 1.1.4+ arrives with substantive notes and supported-version coverage, revisit; if it stays silent, treat the project as archived and plan removal at the next Symfony upgrade.

How to Pitch It (Stakeholders)

One-liner: A small MIT-licensed Symfony bundle that lets each bundle own its own Webpack config, so frontend assets travel with the code that uses them.

For executives: This is a cheap, reversible internal-tooling choice, not a platform bet. It buys us bundle portability and removes a recurring source of config merge conflicts. The cost is low (small surface area, MIT, asset configs stay in plain Webpack, so backing out is mechanical), but the maintenance risk is unchanged in substance: a five-year gap in releases was interrupted only by a single patch (1.1.3) with no release notes and no downstream dependents, so we would still own the code if it breaks. Recommendation: adopt only for internal bundles on our current Symfony version, pin the version we've actually reviewed, name an owner, and set a 12-month review trigger — or skip it and standardize on Symfony's official Webpack Encore.

For engineering: Scope it tightly. Confirm Symfony/Webpack version compatibility first — verify against the 1.1.3 code, not its (empty) notes. Diff the tag, check provenance, then pin; budget a fork-or-patch allowance. Do not let the version bump imply upgraded framework support. Treat asset-config extraction as the exit path. If the actual goal is "bundles ship their own UI," this pattern is worth copying even if we don't take the dependency — a ~200-line internal equivalent may be the better long-term asset than an unmaintained third-party package.

For the roadmap owner: Note the mismatch — this is Symfony, not Laravel. If any of our products are Laravel, the parallel decision is Vite vs. laravel-mix, and it should be tracked separately. Also note that the 1.1.3 release is not a roadmap-relevant event; the only thing that changed is our diligence checklist, not the recommendation.