- Is hostnet/webpack-bundle compatible with Laravel?
- No. hostnet/webpack-bundle is a Symfony bundle that integrates through Symfony's kernel, dependency injection container, console commands, and Twig helpers, none of which map directly to Laravel service providers, Artisan, or Blade. Making it work in Laravel would require forking it, writing a Laravel service provider to bridge its config schema, and reimplementing its Twig helper as a Blade directive. That is more glue code than value, and the package is abandoned.
- How do I install hostnet/webpack-bundle in a Symfony application?
- Install it with Composer, enable the bundle in your Symfony bundles configuration, and configure the Webpack manifest path and entrypoints. Templates then use the bundle's Twig helpers to reference compiled JavaScript and CSS. For new Symfony work, use symfony/webpack-encore instead because hostnet/webpack-bundle is no longer maintained.
- What does hostnet/webpack-bundle actually do?
- It reads a Webpack manifest, resolves compiled JavaScript and CSS with cache-busting filenames, and exposes those assets to Symfony Twig templates through helpers. It also supports a Webpack dev server for local development and configurable entrypoints. It does not compile assets itself; Node and Webpack do that work.
- How do the Twig helpers resolve Webpack entrypoints and assets?
- The helpers read the Webpack manifest mapping logical entrypoint names to hashed output filenames. Templates call the helpers to emit the correct script and link tags for compiled JavaScript and CSS. In Laravel you would need an equivalent Blade directive, which the bundle does not provide.
- Does hostnet/webpack-bundle support the Webpack dev server?
- Yes, the package documents dev server support for local development, alongside manifest-based resolution for production assets. However, the package is abandoned, and its pinned Node, Webpack, and loader versions may no longer work on current environments. Modern Laravel and Symfony tooling such as Vite handles hot module replacement natively.
- Is hostnet/webpack-bundle still maintained?
- No. The repository is archived, and release 2.0.8 is an abandonment notice published on a patch version rather than a functional change. There is no security response channel and no CVE triage, so no fixes will arrive. The README points consumers toward alternatives, and Symfony projects should migrate to symfony/webpack-encore.
- What are the best alternatives to hostnet/webpack-bundle for Laravel?
- For Laravel, use laravel-vite-plugin with Vite as the first-party supported path, or laravel-mix if you are on an older frontend workflow. Both are Laravel-native, maintained, and handle manifest resolution, cache busting, and development server support. For Symfony applications, symfony/webpack-encore is the maintained successor in the same lineage.
- Can I use hostnet/webpack-bundle with Laravel Blade templates?
- Not directly. Its template integration is built around Twig helpers, and those do not map to Blade without an adapter you would have to own. A realistic Laravel integration means forking the bundle, writing a service provider, and creating a Blade directive. Laravel's native @vite directive already solves this with no fork required.
- What are the production risks of keeping hostnet/webpack-bundle?
- The risk is high because the package is formally abandoned with no security response process. Known decay includes node-sass native builds failing on current Node and glibc, and Node 17+ removing the MD4 hash that older Webpack builds relied on, producing ERR_OSSL_EVP_UNSUPPORTED. The PHP source likely targets PHP 7.x semantics. The MIT license allows internal patching or vendoring, but that is the only way to keep the code alive.
- How do I migrate away from hostnet/webpack-bundle?
- For Symfony, migrate to symfony/webpack-encore, which is the maintained successor with the same general approach. For Laravel, replace it with Vite and laravel-vite-plugin or laravel-mix, then swap Twig helpers for Blade's native asset directives. Read the bundle README as the de facto migration note, inventory any pinned Node, Webpack, and loader versions, and update your CI image before removing the dependency.