Weave Code
Hot Reload Bundle Laravel Package
nowo-tech/hot-reload-bundle
Symfony bundle that brings hot reloading to your development workflow. It automatically refreshes the browser when templates, assets, or PHP files change, so you can iterate faster and skip manual reloads. Lightweight and easy to install.
Symfony bundle that injects FrankenPHP (Dunglas) Hot Reload client assets when FRANKENPHP_HOT_RELOAD is available.
Frequently asked questions about Hot Reload Bundle
- Does nowo-tech/hot-reload-bundle work with Laravel?
- No. This is a Symfony bundle with no Laravel integration surface: it ships no service provider, facade, or config file, so Composer may install it but Laravel will never register or boot it. Laravel has no equivalent of Symfony's config/bundles.php registration mechanism, so none of the auto-injection logic ever runs. If you want FrankenPHP hot reload in a Laravel app, add the FrankenPHP client script to a Blade partial yourself behind an environment check.
- How do I install nowo-tech/hot-reload-bundle?
- Install it as a dev dependency with composer require --dev nowo-tech/hot-reload-bundle, then register it in config/bundles.php under the dev key. Set FRANKENPHP_HOT_RELOAD in your .env.dev or Docker Compose environment and serve the app with FrankenPHP in dev mode. Realistically the whole setup plus verification is about half a day of work.
- Which PHP and Symfony versions does this bundle support?
- The maintainer rules target PHP >=8.1 <8.6 with Symfony 7.4, 8.0, and 8.1 actually exercised in CI, while composer.json keeps a broader ^6.0 || ^7.0 || ^8.0 constraint. That gap matters: a Symfony 6.4 LTS shop may resolve the package cleanly but is untested rather than supported. Symfony 8 also requires PHP 8.4+, which further fragments the compatibility matrix for teams on PHP 8.1 or 8.2.
- How does the bundle decide when to inject the hot reload script?
- It detects the FRANKENPHP_HOT_RELOAD environment variable and injects the FrankenPHP (Dunglas) hot reload client asset into rendered pages. That eliminates a hand-maintained script tag and an env-specific template conditional from every project. Before adopting it, check the source to confirm whether injection is also hard-gated to kernel.environment === 'dev' or whether the environment variable alone is the trigger.
- Is it safe to enable this bundle in production?
- It is a development-only convenience and should never be active in prod. The risk is that if injection keys off the environment variable alone with no environment guard, a stray FRANKENPHP_HOT_RELOAD value in a production container would inject a client pointing at a dev server. Verify the injection path has a dev gate, and only define the variable in dev env files as a second layer of protection.
- Will it conflict with Vite or Symfony Encore HMR?
- Possibly. The repository's own pipeline uses Vite with TypeScript and prebuilt assets under src/Resources/public/build, so running the Vite dev server in the same page as FrankenPHP hot reload is a plausible double-reload or conflicting-refresh scenario. Test both active simultaneously instead of assuming they coexist.
- Does it support CSP nonces or Subresource Integrity?
- There is no documented support for CSP nonces or SRI hashes. If the bundle emits a bare script src tag, a strict script-src policy will block it during development, which is recoverable by relaxing the dev-only policy but still a surprise. Inspect the emitted markup before relying on it behind a strict CSP.
- Does it work with FrankenPHP worker mode?
- That is not documented. Since the bundle only injects a client asset, worker-mode compatibility depends on whether the page rendering path still flows through the injector when FrankenPHP runs in worker mode. Test both classic mode and worker mode explicitly in your own container setup.
- Is this package actively maintained and can I trust it?
- Treat it as a single-maintainer package with essentially no community signal: zero stars, zero dependents, and no dependents of dependents. The reported last release date is in the future, which is a metadata artifact you should verify against Packagist and Composer metadata before pinning a version. The mitigations are MIT licensing and a tiny surface of a handful of classes, so forking in place is cheap insurance.
- What exactly does it inject, and will it break Turbo or HTMX partial swaps?
- It injects the FrankenPHP hot reload client script into rendered pages, but the overview does not state whether the mechanism is a Twig function, a render event listener, or a kernel.response filter. If it is a response filter, it may duplicate or re-inject the script on Turbo or HTMX partial swaps. Confirm the implementation before pairing it with a partial-navigation frontend.
Weaver
How can I help you explore Laravel packages today?