Symfony Reprise 1.0 se publicó el 26 de agosto de 2026. El proyecto proporciona a Vite y Rsbuild la capa de integración que necesita una aplicación Symfony: puntos de entrada, manifiestos, funciones Twig, servidor de desarrollo, Symfony UX, CDN y Subresource Integrity. La versión 1.0 elimina el estado experimental y sitúa la API pública bajo versionado semántico y una promesa de compatibilidad con Symfony. Esto lo convierte en un candidato serio para sustituir Webpack Encore, pero no en una migración automática.
Idea clave: Reprise no es un nuevo bundler. Vite o Rsbuild realizan la compilación; Reprise produce los archivos y las convenciones que espera Symfony. El proyecto reduce la fricción de la migración, pero todavía hay que inventariar los comportamientos de Encore, elegir un bundler, validar los assets copiados, el desarrollo local, Symfony UX, la caché y el despliegue.
1. Qué estabiliza realmente Reprise 1.0
La publicación de Reprise 1.0 no corresponde a la incorporación de una larga lista de funciones. Sobre todo, constituye un compromiso de estabilidad. Según el anuncio de Symfony, la API pública sigue ahora el versionado semántico y la promesa de compatibilidad del framework: una ruptura debe pasar por una deprecación antes de una futura versión mayor.
Este punto es importante para los equipos que dudaban en basar su cadena de assets en un componente que todavía se presentaba como experimental. La serie de versiones anteriores reforzó principalmente las pruebas de extremo a extremo, el soporte de la integridad de subrecursos, el playground y la guía de migración desde Encore.
No obstante, sigue siendo necesaria la prudencia. Symfony indica explícitamente que Reprise todavía es joven. Una versión 1.0 significa que la interfaz pública está estabilizada; no demuestra que todos los casos particulares encontrados durante años de proyectos Encore estén ya cubiertos. Un piloto sobre una aplicación real sigue siendo indispensable.
2. Una capa Symfony, no un competidor de Vite o Rsbuild
Webpack Encore combinaba una configuración simplificada de Webpack con una integración estrecha con Symfony. Reprise adopta una separación más clara. Vite o Rsbuild se encargan de TypeScript, Sass, PostCSS, JSX, Vue o Svelte, la división del código, los mapas de origen, la minificación y la recarga en caliente. Reprise no vuelve a implementar estas funciones.
Su responsabilidad es producir y leer las convenciones útiles para el backend: entrypoints.json, manifest.json, la resolución de archivos con hash, las funciones Twig, la conexión con el servidor de desarrollo, la gestión de varias compilaciones, la copia de archivos, la compatibilidad con Symfony UX y la posible incorporación de hashes SRI.
Esta arquitectura evita crear una abstracción completa sobre los bundlers. Permite utilizar sus funciones nativas conservando una experiencia Symfony homogénea. A cambio, exige comprender en qué nivel se configura cada necesidad. Un alias de JavaScript, un plugin de Vue o una optimización del bundle pertenecen al bundler; la generación de etiquetas Twig y la relación con el componente Asset pertenecen a Reprise.
Esta distinción debe quedar registrada en la documentación del proyecto para evitar una configuración dispersa o redundante.
3. Elegir entre Vite y Rsbuild
Reprise es compatible con Vite y Rsbuild. La elección no debe basarse únicamente en la popularidad o en un benchmark genérico.
Vite cuenta con un ecosistema muy amplio, una adopción sólida y una experiencia de desarrollo conocida por muchos equipos frontend. A menudo es la elección natural para proyectos Vue, React, Svelte o JavaScript clásico que ya disponen de plugins de Vite.
Rsbuild se apoya en el ecosistema Rspack y busca una compatibilidad importante con los usos procedentes de Webpack, prestando especial atención al rendimiento de las compilaciones. Puede resultar interesante cuando un proyecto tiene una configuración compleja o hábitos más cercanos a Webpack, siempre que se compruebe cada plugin utilizado realmente.
Construye una prueba representativa: una entrada pública, una entrada de administración, Sass, algunas importaciones dinámicas, un controlador Stimulus, assets copiados y una compilación de producción. Compara el tiempo de arranque, el tiempo de compilación, la estabilidad del HMR, el tamaño de las salidas, la compatibilidad de los plugins y la legibilidad de la configuración.
El mejor bundler es aquel que el equipo sabe utilizar, diagnosticar y mantener con las dependencias del proyecto.
4. Cartografiar el Webpack Encore existente
Antes de modificar la configuración, inventaría cada llamada Encore.* y cada comportamiento indirecto. La guía oficial de Reprise ofrece una correspondencia método por método, lo que facilita este trabajo, pero no sustituye el análisis del resultado esperado.
Registra los puntos de entrada, los chunks compartidos, los archivos estáticos copiados, los alias, las variables de entorno, los loaders específicos, los plugins, los polyfills, los controladores Stimulus, los paquetes Symfony UX, los posibles bundles múltiples y las rutas utilizadas por las plantillas o el código PHP.
Inspecciona también el despliegue: ¿dónde se ejecuta la compilación? ¿Se conserva el directorio public/build entre las etapas? ¿Se envían las imágenes a un CDN? ¿Espera el servidor un entrypoints.json al arrancar? ¿Se precargan los archivos o están sujetos a una Content Security Policy?
Muchos incidentes de migración no proceden de la compilación del JavaScript principal, sino de un logo copiado a una ruta estable, un worker, una fuente, un archivo de traducción o un script cargado por una página que se prueba rara vez.
Crea una matriz «comportamiento actual / responsable / equivalente / prueba de validación». Se convertirá en el contrato de migración.
5. Migrar las plantillas, las entradas y Symfony UX
En el caso habitual, los helpers Twig pasan de encore_entry_script_tags y encore_entry_link_tags a sus equivalentes reprise_entry_script_tags y reprise_entry_link_tags. La forma general sigue siendo parecida, pero el resultado utiliza módulos ES y el funcionamiento del servidor de desarrollo depende del bundler elegido.
Empieza reproduciendo los mismos nombres de entrada. Esto limita los cambios en las plantillas y permite comparar página por página. No aproveches la migración para renombrar todas las entradas, reorganizar los directorios y rehacer el JavaScript al mismo tiempo.
Para Symfony UX y Stimulus, Reprise puede leer controllers.json y registrar controladores locales o proporcionados por paquetes. Sin embargo, comprueba las necesidades propias de cada paquete: una hoja de estilos o un asset diseñado para un loader de Webpack puede necesitar un alias o una configuración adaptada con Vite o Rsbuild.
Los controladores cargados de forma diferida, las importaciones dinámicas y los componentes Turbo deben probarse mediante recorridos de navegación completa. Una primera visualización correcta no garantiza que los cambios de página, los modales o los formularios reinicien correctamente su estado.
Los equipos que también modernicen sus herramientas PHP pueden relacionar este trabajo con los cambios descritos en nuestro artículo sobre Symfony Language Tools y el LSP oficial, manteniendo lotes independientes para facilitar el diagnóstico.
6. Proteger manifiestos, CDN, caché e integridad
Reprise genera un entrypoints.json y un manifest.json compatibles con las necesidades de Symfony. Comprueba que estos archivos se produzcan en todos los entornos y estén presentes en el artefacto final. Una imagen Docker construida en varias etapas puede compilar los assets y después olvidar copiar el directorio de salida.
Los archivos referenciados directamente desde Twig o PHP deben estar cubiertos por la estrategia de copia y de manifiesto. Por defecto, un nombre con hash facilita la invalidación de la caché. Mantener una ruta estable puede ser necesario para un favicon, un manifiesto web o un sistema externo, pero en ese caso hay que asegurarse de que el CDN o el proxy tenga en cuenta la cadena de consulta utilizada para versionar.
Con un CDN, el publicPath de producción y el prefijo de las claves del manifiesto deben coincidir. Prueba el entorno real: origen, HTTPS, CORS, caché, compresión y purga. Una URL correcta en el archivo no garantiza que el archivo se haya publicado realmente.
Reprise puede añadir hashes de Subresource Integrity a los scripts y las hojas de estilo. Esta protección es relevante en producción, pero debe coordinarse con las transformaciones realizadas después de la compilación. Un CDN que reescriba el contenido invalidaría el hash.
Por último, comprueba los atributos necesarios para tu Content Security Policy, especialmente los nonces. Reprise expone un evento que permite personalizar las etiquetas generadas; este punto debe probarse en vez de añadirse después de la transición.
7. Organizar una transición progresiva
La migración más segura comienza con una rama dedicada y una compilación paralela. Conserva temporalmente la salida de Encore como referencia y genera después la salida de Reprise en otro directorio. Compara la presencia de las entradas, las URL, los assets copiados y los tamaños de los archivos.
A continuación, automatiza una prueba de renderizado de las páginas principales y una comparación visual. Añade recorridos Playwright que cubran el inicio de sesión, los formularios, los componentes interactivos, las páginas de administración y las pantallas que utilizan entradas específicas.
El pipeline debe ejecutar la compilación de producción, comprobar la existencia y la validez JSON de los manifiestos y después iniciar una aplicación construida a partir del artefacto final. Probar únicamente el servidor de desarrollo no detecta los olvidos de copia ni las rutas de producción.
Para la puesta en producción, prepara una vuelta atrás que restaure tanto el código backend como los assets compatibles. Si el despliegue utiliza releases atómicas, cada release debe incluir su propia compilación para evitar que una plantilla antigua cargue archivos de una versión nueva.
Después de la transición, controla los errores JavaScript, las respuestas 404 de los assets, las infracciones de CSP, la caché del navegador y los tiempos de carga. No elimines Encore ni sus archivos de configuración hasta después de un periodo de observación y una receta completa.
8. Decidir si hay que migrar ahora
Una nueva aplicación Symfony puede evaluar Reprise desde el inicio, sobre todo si el equipo ya domina Vite o Rsbuild. El alcance reducido del componente y la promesa de compatibilidad 1.x ofrecen ahora una base más previsible.
Para una aplicación Encore estable, la migración debe responder a una necesidad: acelerar las compilaciones, simplificar el ecosistema frontend, alinear varios proyectos, reducir una configuración Webpack que se ha vuelto difícil o adoptar plugins modernos. Migrar únicamente porque existe una herramienta más reciente crea riesgo sin un valor claro.
El esfuerzo depende menos del número de líneas de webpack.config.js que de las convenciones acumuladas alrededor de la compilación. Un proyecto sencillo puede cambiar rápidamente. Una plataforma con múltiples entradas, CDN, workers, componentes históricos y extensiones a medida merece un piloto completo.
Reprise 1.0 reduce la incertidumbre técnica. No elimina la necesidad de un inventario, una receta y un plan de vuelta atrás.
Conclusión
Symfony Reprise 1.0 marca una etapa importante para los proyectos que quieren utilizar Vite o Rsbuild sin perder la integración familiar entre los assets y Symfony. Su decisión arquitectónica es acertada: dejar que el bundler compile y proporcionar únicamente la capa de enlace necesaria para el framework.
Una migración exitosa debe seguir siendo incremental. Cartografía los comportamientos de Encore, prueba ambos bundlers en un caso real, reproduce primero las entradas existentes, valida los manifiestos y el despliegue y solo después moderniza la organización del frontend. Partitech acompaña las actualizaciones de Symfony, las migraciones de herramientas y la protección de las cadenas de compilación y despliegue.