Symfony Reprise 1.0 was released on August 26, 2026. The project provides Vite and Rsbuild with the integration layer a Symfony application needs: entry points, manifests, Twig functions, development server, Symfony UX, CDN and Subresource Integrity. Version 1.0 removes the experimental status and places the public API under semantic versioning and a Symfony compatibility promise. This makes it a serious candidate to replace Webpack Encore, but not an automatic migration.
Key takeaway: Reprise is not a new bundler. Vite or Rsbuild perform the compilation; Reprise produces the files and conventions expected by Symfony. The project reduces migration friction, but you still need to inventory Encore behavior, choose a bundler, validate copied assets, local development, Symfony UX, the cache and deployment.
1. What Reprise 1.0 really stabilizes
The release of Reprise 1.0 does not correspond to adding a long list of features. It is primarily a commitment to stability. According to the Symfony announcement, the public API now follows semantic versioning and the framework's compatibility promise: a breaking change must go through deprecation before a future major version.
This point matters for teams that hesitated to base their asset pipeline on a component still presented as experimental. The previous version series mainly strengthened end-to-end tests, Subresource Integrity support, the playground and the migration guide from Encore.
Caution is nevertheless still required. Symfony explicitly says that Reprise is still young. A 1.0 version means that the public interface is stabilized; it does not prove that every edge case encountered over years of Encore projects is already covered. A pilot on a real application remains essential.
2. A Symfony layer, not a competitor to Vite or Rsbuild
Webpack Encore combined simplified Webpack configuration with close Symfony integration. Reprise adopts a clearer separation. Vite or Rsbuild handle TypeScript, Sass, PostCSS, JSX, Vue or Svelte, code splitting, source maps, minification and hot reloading. Reprise does not reimplement these functions.
Its responsibility is to produce and read the conventions useful to the backend: entrypoints.json, manifest.json, resolving hashed files, Twig functions, connection to the development server, support for multiple builds, file copying, Symfony UX support and the possible addition of SRI hashes.
This architecture avoids creating a complete abstraction over the bundlers. It makes it possible to use their native features while retaining a consistent Symfony experience. In return, it requires understanding which layer controls each need. A JavaScript alias, a Vue plugin or a bundle optimization belongs to the bundler; generating Twig tags and the relationship with the Asset component belong to Reprise.
This distinction should be recorded in the project documentation to avoid scattered or redundant configuration.
3. Choosing between Vite and Rsbuild
Reprise supports Vite and Rsbuild. The choice should not rely solely on popularity or a generic benchmark.
Vite benefits from a very broad ecosystem, strong adoption and a development experience familiar to many frontend teams. It is often the natural choice for Vue, React, Svelte or plain JavaScript projects that already have Vite plugins.
Rsbuild is built on the Rspack ecosystem and aims for significant compatibility with Webpack-based usage, with particular attention to build performance. It can be useful when a project has a complex configuration or practices closer to Webpack, provided that every plugin actually in use is checked.
Build a representative test: a public entry, an administration entry, Sass, a few dynamic imports, a Stimulus controller, copied assets and a production build. Compare startup time, compilation time, HMR stability, output size, plugin compatibility and configuration readability.
The best bundler is the one the team knows how to use, diagnose and maintain with the project's dependencies.
4. Mapping the existing Webpack Encore setup
Before changing the configuration, inventory every Encore.* call and every indirect behavior. The official Reprise guide provides a method-by-method correspondence, which makes this work easier, but it does not replace analysis of the expected result.
Record entry points, shared chunks, copied static files, aliases, environment variables, specific loaders, plugins, polyfills, Stimulus controllers, Symfony UX packages, any multiple bundles and the paths used by templates or PHP code.
Also inspect deployment: where is the build run? Is the public/build directory preserved between steps? Are images sent to a CDN? Does the server expect an entrypoints.json at startup? Are files preloaded or subject to a Content Security Policy?
A large share of migration incidents does not come from compiling the main JavaScript, but from a logo copied to a stable path, a worker, a font, a translation file or a script loaded by a rarely tested page.
Create a “current behavior / owner / equivalent / validation test” matrix. It becomes the migration contract.
5. Migrating templates, entries and Symfony UX
In the common case, Twig helpers change from encore_entry_script_tags and encore_entry_link_tags to their reprise_entry_script_tags and reprise_entry_link_tags equivalents. The general form remains similar, but the result uses ES modules and development-server behavior depends on the selected bundler.
Start by reproducing the same entry names. This limits template changes and enables a page-by-page comparison. Do not use the migration as an opportunity to rename every entry, reorganize directories and rewrite the JavaScript at the same time.
For Symfony UX and Stimulus, Reprise can read controllers.json and register local controllers or controllers supplied by packages. However, check the needs specific to each package: a stylesheet or asset designed for a Webpack loader may require an alias or adapted configuration with Vite or Rsbuild.
Controllers loaded lazily, dynamic imports and Turbo components should be covered by full-navigation tests. A correct first display does not guarantee that page changes, modals or forms correctly reset their state.
Teams also modernizing their PHP tooling can connect this work with the changes described in our article on Symfony Language Tools and the official LSP, while keeping independent batches to simplify diagnosis.
6. Securing manifests, CDN, cache and integrity
Reprise generates an entrypoints.json and a manifest.json compatible with Symfony's needs. Check that these files are produced in every environment and are present in the final artifact. A multi-stage Docker image may compile the assets and then forget to copy the output directory.
Files referenced directly from Twig or PHP must be covered by the copying and manifest strategy. By default, a hashed name makes cache invalidation easier. Keeping a stable path may be necessary for a favicon, a web manifest or an external system, but you must then ensure that the CDN or proxy takes the query string used for versioning into account.
With a CDN, the production publicPath and the manifest key prefix must match. Test the real environment: origin, HTTPS, CORS, cache, compression and purge. A correct URL in the file does not guarantee that the file is actually published.
Reprise can add Subresource Integrity hashes to scripts and stylesheets. This protection is relevant in production, but it must be coordinated with transformations performed after the build. A CDN that rewrites the content would invalidate the hash.
Finally, check the attributes required by your Content Security Policy, especially nonces. Reprise exposes an event for customizing generated tags; this point should be tested rather than added after the switch.
7. Organizing a gradual switch
The safest migration starts with a dedicated branch and a parallel build. Temporarily keep the Encore output as a reference, then generate the Reprise output in another directory. Compare entry presence, URLs, copied assets and file sizes.
Then automate a rendering test for the main pages and a visual comparison. Add Playwright journeys covering login, forms, interactive components, administration pages and screens using specific entries.
The pipeline must run the production build, check the existence and JSON validity of the manifests, then start an application built from the final artifact. Testing only the development server will not detect missing copies or production paths.
For production rollout, prepare a rollback that restores both the backend code and compatible assets. If deployment uses atomic releases, each release must include its own build to prevent an old template from loading files from a newer version.
After the switch, monitor JavaScript errors, 404 responses for assets, CSP violations, browser cache and loading times. Remove Encore and its configuration files only after an observation period and a complete acceptance test.
8. Deciding whether to migrate now
A new Symfony application can evaluate Reprise from the start, especially if the team already knows Vite or Rsbuild. The component's limited scope and the 1.x compatibility promise now provide a more predictable foundation.
For a stable Encore application, migration should answer a need: faster builds, a simpler frontend ecosystem, alignment across several projects, reducing a Webpack configuration that has become difficult, or adopting modern plugins. Migrating simply because a newer tool exists creates risk without clear value.
The effort level depends less on the number of webpack.config.js lines than on the conventions accumulated around the build. A simple project can switch quickly. A multi-entry platform with a CDN, workers, legacy components and custom extensions deserves a complete pilot.
Reprise 1.0 reduces technical uncertainty. It does not remove the need for an inventory, acceptance testing and a rollback plan.
Conclusion
Symfony Reprise 1.0 is an important step for projects that want to use Vite or Rsbuild without losing the familiar integration between assets and Symfony. Its architectural choice is sound: let the bundler compile and provide only the framework's necessary integration layer.
A successful migration should remain incremental. Map Encore behaviors, test both bundlers on a real case, first reproduce the existing entries, validate manifests and deployment, and only then modernize the frontend organization. Partitech supports Symfony upgrades, tooling migrations and the security of build and deployment pipelines.