Symfony Reprise 1.0 è stato pubblicato il 26 agosto 2026. Il progetto fornisce a Vite e Rsbuild il livello di integrazione di cui un'applicazione Symfony ha bisogno: entry point, manifest, funzioni Twig, server di sviluppo, Symfony UX, CDN e Subresource Integrity. La versione 1.0 rimuove lo stato sperimentale e sottopone l'API pubblica al versionamento semantico e a una promessa di compatibilità con Symfony. Questo ne fa un candidato serio per sostituire Webpack Encore, ma non una migrazione automatica.
Da ricordare: Reprise non è un nuovo bundler. Vite o Rsbuild eseguono la compilazione; Reprise produce i file e le convenzioni attese da Symfony. Il progetto riduce l'attrito della migrazione, ma è ancora necessario inventariare i comportamenti di Encore, scegliere un bundler, validare gli asset copiati, lo sviluppo locale, Symfony UX, la cache e il deployment.
1. Che cosa stabilizza davvero Reprise 1.0
La pubblicazione di Reprise 1.0 non coincide con l'aggiunta di una lunga lista di funzioni. Rappresenta soprattutto un impegno di stabilità. Secondo l'annuncio di Symfony, l'API pubblica segue ora il versionamento semantico e la promessa di compatibilità del framework: una modifica incompatibile deve passare da una deprecazione prima di una futura versione maggiore.
Questo punto è importante per i team che esitavano a basare la propria catena di asset su un componente ancora presentato come sperimentale. La serie di versioni precedenti ha soprattutto rafforzato i test end-to-end, il supporto all'integrità delle sotto-risorse, il playground e la guida alla migrazione da Encore.
La prudenza resta comunque necessaria. Symfony indica esplicitamente che Reprise è ancora giovane. Una versione 1.0 significa che l'interfaccia pubblica è stabilizzata; non dimostra che tutti i casi particolari incontrati in anni di progetti Encore siano già coperti. Un pilota su un'applicazione reale resta indispensabile.
2. Un livello Symfony, non un concorrente di Vite o Rsbuild
Webpack Encore combinava una configurazione semplificata di Webpack con un'integrazione stretta con Symfony. Reprise adotta una separazione più netta. Vite o Rsbuild gestiscono TypeScript, Sass, PostCSS, JSX, Vue o Svelte, la suddivisione del codice, le source map, la minificazione e il ricaricamento a caldo. Reprise non reimplementa queste funzioni.
La sua responsabilità è produrre e leggere le convenzioni utili al backend: entrypoints.json, manifest.json, la risoluzione dei file con hash, le funzioni Twig, il collegamento al server di sviluppo, la gestione di più build, la copia dei file, il supporto a Symfony UX e l'eventuale aggiunta di hash SRI.
Questa architettura evita di creare un'astrazione completa sopra i bundler. Permette di utilizzare le loro funzioni native mantenendo un'esperienza Symfony uniforme. In cambio, richiede di capire a quale livello viene configurata ogni esigenza. Un alias JavaScript, un plugin Vue o un'ottimizzazione del bundle appartengono al bundler; la generazione dei tag Twig e il rapporto con il componente Asset appartengono a Reprise.
Questa distinzione deve essere inserita nella documentazione del progetto per evitare una configurazione dispersa o ridondante.
3. Scegliere tra Vite e Rsbuild
Reprise supporta Vite e Rsbuild. La scelta non deve basarsi soltanto sulla popolarità o su un benchmark generico.
Vite dispone di un ecosistema molto ampio, di un'adozione forte e di un'esperienza di sviluppo conosciuta da molti team frontend. Spesso è la scelta naturale per progetti Vue, React, Svelte o JavaScript classico che dispongono già di plugin Vite.
Rsbuild si basa sull'ecosistema Rspack e punta a un'importante compatibilità con gli utilizzi derivati da Webpack, con particolare attenzione alle prestazioni di build. Può essere interessante quando un progetto possiede una configurazione complessa o abitudini più vicine a Webpack, a condizione di verificare ogni plugin realmente utilizzato.
Costruite un test rappresentativo: un'entry pubblica, un'entry di amministrazione, Sass, alcuni import dinamici, un controller Stimulus, asset copiati e una build di produzione. Confrontate il tempo di avvio, il tempo di compilazione, la stabilità dell'HMR, la dimensione degli output, la compatibilità dei plugin e la leggibilità della configurazione.
Il bundler migliore è quello che il team sa utilizzare, diagnosticare e mantenere con le dipendenze del progetto.
4. Mappare l'esistente Webpack Encore
Prima di modificare la configurazione, inventariate ogni chiamata Encore.* e ogni comportamento indiretto. La guida ufficiale di Reprise fornisce una corrispondenza metodo per metodo, che facilita il lavoro, ma non sostituisce l'analisi del risultato atteso.
Rilevate gli entry point, i chunk condivisi, i file statici copiati, gli alias, le variabili d'ambiente, i loader specifici, i plugin, i polyfill, i controller Stimulus, i pacchetti Symfony UX, gli eventuali bundle multipli e i percorsi utilizzati dai template o dal codice PHP.
Esaminate anche il deployment: dove viene eseguita la build? La directory public/build viene conservata tra le fasi? Le immagini vengono inviate a un CDN? Il server si aspetta un entrypoints.json all'avvio? I file vengono precaricati o sono soggetti a una Content Security Policy?
Una parte consistente degli incidenti di migrazione non deriva dalla compilazione del JavaScript principale, ma da un logo copiato in un percorso stabile, da un worker, da un font, da un file di traduzione o da uno script caricato da una pagina testata raramente.
Create una matrice «comportamento attuale / responsabile / equivalente / test di validazione». Diventerà il contratto di migrazione.
5. Migrare template, entry e Symfony UX
Nel caso comune, gli helper Twig passano da encore_entry_script_tags e encore_entry_link_tags ai loro equivalenti reprise_entry_script_tags e reprise_entry_link_tags. La forma generale resta simile, ma il risultato utilizza moduli ES e il funzionamento del server di sviluppo dipende dal bundler scelto.
Iniziate riproducendo gli stessi nomi delle entry. Questo limita i cambiamenti nei template e consente un confronto pagina per pagina. Non approfittate della migrazione per rinominare tutte le entry, riorganizzare le directory e riscrivere contemporaneamente il JavaScript.
Per Symfony UX e Stimulus, Reprise può leggere controllers.json e registrare i controller locali o forniti dai pacchetti. Verificate però le esigenze specifiche di ogni pacchetto: un foglio di stile o un asset progettato per un loader Webpack può richiedere un alias o una configurazione adattata con Vite o Rsbuild.
I controller caricati in modo differito, gli import dinamici e i componenti Turbo devono essere sottoposti a test di navigazione completa. Una prima visualizzazione corretta non garantisce che i cambi di pagina, le modali o i moduli reimpostino correttamente il proprio stato.
I team che modernizzano anche gli strumenti PHP possono collegare questo lavoro alle evoluzioni descritte nel nostro articolo su Symfony Language Tools e l'LSP ufficiale, mantenendo lotti indipendenti per semplificare la diagnosi.
6. Proteggere manifest, CDN, cache e integrità
Reprise genera un entrypoints.json e un manifest.json compatibili con le esigenze di Symfony. Verificate che questi file siano prodotti in tutti gli ambienti e siano presenti nell'artefatto finale. Un'immagine Docker costruita in più fasi può compilare gli asset e poi dimenticare di copiare la directory di output.
I file referenziati direttamente da Twig o PHP devono essere coperti dalla strategia di copia e di manifest. Per impostazione predefinita, un nome con hash facilita l'invalidazione della cache. Conservare un percorso stabile può essere necessario per una favicon, un manifest web o un sistema esterno, ma occorre assicurarsi che il CDN o il proxy tenga conto della query string usata per il versionamento.
Con un CDN, il publicPath di produzione e il prefisso delle chiavi del manifest devono corrispondere. Testate l'ambiente reale: origine, HTTPS, CORS, cache, compressione e purge. Un URL corretto nel file non garantisce che il file sia effettivamente pubblicato.
Reprise può aggiungere hash Subresource Integrity a script e fogli di stile. Questa protezione è pertinente in produzione, ma deve essere coordinata con le trasformazioni eseguite dopo la build. Un CDN che riscrivesse il contenuto renderebbe l'hash non valido.
Infine, verificate gli attributi necessari alla vostra Content Security Policy, in particolare i nonce. Reprise espone un evento per personalizzare i tag generati; questo punto deve essere testato, non aggiunto dopo il passaggio.
7. Organizzare un passaggio progressivo
La migrazione più sicura inizia con un branch dedicato e una build parallela. Conservate temporaneamente l'output Encore come riferimento, poi generate l'output Reprise in un'altra directory. Confrontate la presenza delle entry, gli URL, gli asset copiati e le dimensioni dei file.
Automatizzate quindi un test di rendering delle pagine principali e un confronto visivo. Aggiungete percorsi Playwright che coprano il login, i moduli, i componenti interattivi, le pagine di amministrazione e le schermate che utilizzano entry specifiche.
La pipeline deve eseguire la build di produzione, verificare l'esistenza e la validità JSON dei manifest e poi avviare un'applicazione costruita a partire dall'artefatto finale. Testare solo il server di sviluppo non rileva le copie dimenticate o i percorsi di produzione.
Per la messa in produzione, preparate un rollback che ripristini sia il codice backend sia gli asset compatibili. Se il deployment utilizza release atomiche, ogni release deve contenere la propria build per evitare che un template vecchio carichi file di una versione nuova.
Dopo il passaggio, monitorate gli errori JavaScript, le risposte 404 sugli asset, le violazioni CSP, la cache del browser e i tempi di caricamento. Eliminate Encore e i suoi file di configurazione solo dopo un periodo di osservazione e un collaudo completo.
8. Decidere se migrare ora
Una nuova applicazione Symfony può valutare Reprise fin dall'inizio, soprattutto se il team conosce già Vite o Rsbuild. L'ambito ridotto del componente e la promessa di compatibilità 1.x offrono ora una base più prevedibile.
Per un'applicazione Encore stabile, la migrazione deve rispondere a un'esigenza: accelerare le build, semplificare l'ecosistema frontend, allineare più progetti, ridurre una configurazione Webpack diventata difficile o adottare plugin moderni. Migrare solo perché esiste uno strumento più recente crea rischio senza un valore chiaro.
Il livello di sforzo dipende meno dal numero di righe di webpack.config.js che dalle convenzioni accumulate intorno alla build. Un progetto semplice può passare rapidamente. Una piattaforma con più entry, CDN, worker, componenti storici ed estensioni personalizzate merita un pilota completo.
Reprise 1.0 riduce l'incertezza tecnica. Non elimina la necessità di un inventario, di un collaudo e di un piano di rollback.
Conclusione
Symfony Reprise 1.0 rappresenta un passaggio importante per i progetti che vogliono utilizzare Vite o Rsbuild senza perdere la familiare integrazione tra asset e Symfony. La sua scelta architetturale è corretta: lasciare al bundler la compilazione e fornire soltanto il livello di collegamento necessario al framework.
Una migrazione riuscita deve restare incrementale. Mappate i comportamenti di Encore, testate entrambi i bundler su un caso reale, riproducete prima le entry esistenti, validate manifest e deployment e solo dopo modernizzate l'organizzazione del frontend. Partitech accompagna gli aggiornamenti Symfony, le migrazioni degli strumenti e la sicurezza delle pipeline di build e deployment.