Weave Code
Integrate Vite and Rsbuild with Symfony, a reprise of Webpack Encore Bundle.
Frequently asked questions about Reprise
- Is symfony/reprise compatible with Laravel?
- No. Reprise is a Symfony bundle that bridges Vite and Rsbuild into a Symfony application through Twig tag renderers, Symfony DI/HttpKernel wiring, and a dev-server proxy. Laravel already owns this problem with laravel-vite-plugin, the Vite facade, and Blade, so adopting Reprise there would duplicate an existing, better-supported path and introduce Twig as an unnecessary dependency. The realistic fit is a Symfony/Twig surface or a multi-framework design-system scenario where one asset pipeline must serve both.
- How do I install symfony/reprise in a Symfony app?
- Install it with Composer and enable the Symfony bundle, then configure it for the bundler output your app uses. The concrete prerequisites are Twig, Symfony DI/HttpKernel wiring, a bundler that emits the expected manifest shape, and a place in the request lifecycle for the dev-server proxy and header injection. Follow the package documentation for the exact bundle registration and configuration keys.
- Does symfony/reprise require Twig?
- Yes. Reprise renders script, link, and modulepreload tags through Twig tag renderers, so Twig is part of the integration model. That makes it a natural fit for Symfony/Twig estates and an awkward fit for a Laravel-first codebase that uses Blade. If you are not operating a Twig surface, the correct disposition is to evaluate rather than adopt.
- What JavaScript bundlers does symfony/reprise support?
- Reprise supports Vite and Rsbuild and is described as a reprise of the Webpack Encore Bundle. It consumes bundler artifacts such as entrypoints.json and manifest.json, renders the appropriate tags, and serves a dev-server proxy. Your bundler must emit the manifest shape Reprise expects.
- What Laravel version support does symfony/reprise have?
- None is declared because this is a Symfony bundle, not a Laravel package. Laravel version support is not applicable, and adopting it into Laravel request handling is not the intended path. For Symfony, verify the declared PHP and Symfony constraints and whether Symfony 8.1 testing in CI implies 8.0 is untested or dropped.
- What breaking changes are in symfony/reprise 1.3.0?
- The release is a minor bump from 1.2.0 to 1.3.0 with no declared breaking changes, and the removals look internal: the ViteOutputChunk type, the joinUrl helper, and bundler hooks relocated to per-bundler modules. Three changes are behavior-visible and should be verified before pinning: trailing-slash normalization of publicPath and manifestKeyPrefix, joinUrl removal if you subclass or unit-test Reprise internals, and CSP nonce propagation plus preload header order changes. The trailing-slash normalization is the highest-probability silent breakage because URL-joining code, config, or CDN rewrite rules may assume the prior exact string.
- Can I use symfony/reprise with a strict Content Security Policy?
- Yes, and version 1.3.0 improves this by propagating CSP nonces to modulepreload Link headers and making the preload header follow the final tag. These are net-positive for strict-CSP adoption, but they change response headers. Review edge and CDN caching rules plus any header-snapshot tests, and confirm nonce handling in your configuration.
- How does symfony/reprise handle production assets and caching?
- Reprise consumes bundler artifacts such as entrypoints.json and manifest.json and renders the tags Symfony needs. Version 1.3.0 adds atomic emission of entrypoints.json and manifest.json for safe concurrent reads and fixes cache correctness when entrypoints.json is missing, which addresses a stale-cache lockout class of bug. Still validate production behavior because publicPath and manifestKeyPrefix trailing-slash normalization can affect emitted URLs and manifest lookup keys.
- Is symfony/reprise safe for production?
- The technical risk is assessed as low-to-medium based solely on the published changelog, with no vendor review, repository audit, or dependency-graph inspection yet. The package is additive and config-driven, but you should verify trailing-slash normalization, response-header changes, declared PHP and Symfony constraints, license compatibility, and maintenance cadence before pinning. Single-maintainer concentration is a continuity risk worth naming.
- What are alternatives to symfony/reprise for Laravel?
- For Laravel, the existing alternative is laravel-vite-plugin with the Vite facade and Blade, which is already the better-supported path for Laravel asset handling. For Symfony, the predecessor is Webpack Encore Bundle, while Reprise replaces hand-rolled manifest parsing and tag emission on Symfony/Twig surfaces. For a Laravel-first stack, do not introduce Reprise into request handling; evaluate it only if you actually operate a Symfony/Twig surface.
Weaver
How can I help you explore Laravel packages today?