Symfony Reprise : la relève de Webpack Encore est là (et AssetMapper n'est pas mort pour autant)
Une page se tourne dans l'écosystème front de Symfony
Depuis 2017, quand on parlait d'assets dans une application Symfony, on parlait de Webpack Encore. Créé par Ryan Weaver, cet outil a rendu Webpack fréquentable pour des générations de développeurs PHP qui ne demandaient qu'une chose : compiler leur Sass et leur JavaScript sans y laisser un week-end. Puis AssetMapper est arrivé en 2023 avec sa philosophie no-build, et le paysage s'est fragmenté. Deux outils officiels, deux visions opposées, et un trou béant au milieu pour tous les projets qui avaient réellement besoin d'un bundler moderne.
Ce trou vient d'être comblé. Le dépôt symfony/reprise est passé public en juillet 2026, et son sous-titre annonce la couleur : « Webpack Encore's heritage, for modern bundlers ». Reprise intègre Vite et Rsbuild à Symfony, exactement comme Encore intégrait Webpack. Le nom n'est pas un hasard : en musique, une reprise, c'est rejouer un morceau connu avec des instruments modernes.
J'ai épluché le dépôt, la documentation et l'annonce de Symfony UX 3.3.0 qui l'accompagne. Voici ce que Reprise change concrètement, ce qu'il ne change pas, et pourquoi la question « AssetMapper va-t-il disparaître ? » mérite une réponse plus nuancée qu'un oui ou un non.
Pourquoi Encore devait passer la main
Soyons honnêtes : le problème n'a jamais été Encore lui-même. L'API Encore.addEntry() reste l'une des abstractions les plus agréables jamais posées sur Webpack. Le problème, c'est Webpack. Face à Vite, esbuild, Rspack ou Rolldown, il accuse son âge : démarrage lent, configuration verbeuse, écosystème de loaders qui s'essouffle. Pendant que le monde JavaScript migrait en masse, les projets Symfony restaient coincés avec un bundler que plus personne ne choisirait en 2026 pour démarrer un projet.
Le déclic public date de février 2025 : Hugo Alliaume ouvre la RFC #59707 sur le dépôt Symfony, constatant qu'Encore « tend à être déprécié, non pas à cause d'Encore lui-même, mais à cause de Webpack ». Sa proposition : ne pas réinventer la roue, mais créer un plugin dédié pour un bundler moderne, accompagné d'un petit bundle Symfony pour lire le manifest et générer les balises. La communauté avait d'ailleurs déjà défriché le terrain avec le vite-bundle de lhapaipai, solution non officielle mais éprouvée.
Dix-sept mois plus tard, Reprise matérialise exactement cette vision, sous l'organisation symfony, avec Hugo Alliaume aux commandes. Premier commit en septembre 2025, dépôt rendu public en juillet 2026, et déjà un support de premier rang dans StimulusBundle. Le message est limpide : c'est la succession officielle.
Reprise n'est pas un bundler, et c'est toute son intelligence
La décision architecturale la plus importante de Reprise tient en une phrase de sa documentation : Vite et Rsbuild gèrent déjà nativement Sass, TypeScript, JSX, Vue, Svelte, le code splitting, le hashing, les source maps, la minification et le HMR — donc Reprise ne réimplémente rien de tout ça. Là où Encore enveloppait Webpack dans une API maison (avec le risque de toujours courir derrière), Reprise se contente de la « glue » côté Symfony que les bundlers ne fournissent pas :
- Génération d'
entrypoints.jsonetmanifest.jsonau format compatible Encore, en build comme en dev. - Fonctions Twig (
reprise_entry_script_tags,reprise_entry_link_tags) qui rendent les balises directement depuis ces fichiers. - Dev server et HMR : Twig pointe automatiquement vers le serveur Vite ou Rsbuild en cours d'exécution.
- Copie de fichiers statiques (images, fontes) avec hash de contenu, intégrée au manifest pour le helper
asset(). - CDN et Subresource Integrity : URL absolues en production et hashes SRI injectés dans les balises générées.
- Stimulus et Symfony UX : enregistrement de
controllers.jsonet des contrôleurs locaux, en eager ou lazy.
Concrètement, l'installation tient en deux commandes (composer require symfony/reprise puis npm install @symfony/reprise --save-dev) et un plugin à déclarer dans la config du bundler. Voici à quoi ressemble une configuration Vite avec Stimulus activé :
// vite.config.ts
import { defineConfig } from 'vite'
import Symfony from '@symfony/reprise/vite'
export default defineConfig({
build: {
rollupOptions: {
input: {
app: './assets/app.js',
},
},
},
plugins: [
Symfony({
stimulus: 'assets/controllers.json',
copy: [
{ from: 'assets/images', to: 'images' },
],
}),
],
})Migrer depuis Encore : un échange balise pour balise
Si vous venez d'Encore, la migration côté templates est délibérément triviale. Reprise conserve la forme exacte des fonctions Twig d'Encore — seul le préfixe change. La documentation parle d'un tag-for-tag swap, et c'est littéral :
| Webpack Encore | Symfony Reprise | Sortie |
|---|---|---|
encore_entry_link_tags('app') | reprise_entry_link_tags('app') | Balises <link rel="stylesheet"> |
encore_entry_script_tags('app') | reprise_entry_script_tags('app') | Balises <script type="module"> |
encore_entry_css_files('app') | reprise_entry_css_files('app') | Liste d'URL CSS |
encore_entry_js_files('app') | reprise_entry_js_files('app') | Liste d'URL JS |
Une différence mérite l'attention : Reprise génère des modules ES natifs (<script type="module">), là où Encore produisait des scripts classiques. Le reste du confort est préservé : le mode strict_mode lève une exception claire sur une entrée manquante, l'option cache compile entrypoints.json en PHP au cache:warmup pour éviter de décoder du JSON à chaque requête, et les en-têtes de preload HTTP/2 via WebLink sont actifs par défaut. Ce sont des détails, mais des détails qui montrent que l'outil a été pensé par quelqu'un qui exploite réellement des applications Symfony en production.
Encore, AssetMapper, Reprise : trois outils, deux philosophies
Pour situer Reprise, il faut comprendre que ces trois outils ne jouent pas dans la même catégorie. Encore et Reprise partagent une philosophie build : Node.js, un bundler, une étape de compilation. AssetMapper joue seul dans la catégorie no-build : tout en PHP, des import maps natives du navigateur, zéro dépendance Node.
| Critère | Webpack Encore | AssetMapper | Reprise |
|---|---|---|---|
| Bundler | Webpack | Aucun (import maps) | Vite ou Rsbuild |
| Node.js requis | Oui | Non | Oui |
| Vue SFC / JSX natif | Oui | Non | Oui |
| HMR | Oui (lent) | Non (rechargement) | Oui (instantané) |
| TypeScript | Oui | Précompilation manuelle | Oui |
| Statut en 2026 | Maintenu, en fin de vie | Recommandé (nouveaux projets) | Expérimental |
Cette lecture change la question de fond. Reprise ne vient pas concurrencer AssetMapper : il vient remplacer Encore sur son propre terrain, celui des projets qui ont besoin d'une vraie toolchain JavaScript. Le choix entre Vite et Rsbuild à l'intérieur de Reprise est ensuite affaire de contexte : Vite est le standard de fait de l'écosystème, Rsbuild (construit sur Rspack, en Rust) offre un modèle mental plus proche de Webpack, ce qui adoucit la migration des grosses configs Encore historiques.
Symfony UX : le talon d'Achille d'AssetMapper enfin traité
C'est ici que Reprise règle un vrai problème de terrain. AssetMapper a une limite structurelle documentée noir sur blanc par Symfony : les fichiers qui ne sont pas du JavaScript pur ne peuvent pas être servis tels quels au navigateur. Pour symfony/ux-react, il faut installer Babel à côté et précompiler ses .jsx vers un dossier de build — un bricolage qui contredit la promesse du no-build. Pour symfony/ux-vue, c'est pire : les Single File Components mêlent template, script et style dans un même fichier, et rien ne peut les compiler vers du JavaScript exécutable sans bundler complet. Ryan Weaver lui-même, créateur d'AssetMapper, a reconnu ne pas avoir trouvé de solution pour les SFC sur ux.symfony.com et s'être rabattu sur la clé template de Vue — c'est-à-dire renoncer aux SFC.
Avec Reprise, cette limite disparaît par construction. Vite et Rsbuild compilent nativement les SFC Vue, le JSX et le TypeScript : il suffit d'ajouter le plugin officiel du framework (@vitejs/plugin-vue côté Vite, @rsbuild/plugin-vue côté Rsbuild) à côté du plugin Symfony. La RFC d'origine montrait d'ailleurs une config Rsbuild complète avec Vue 3 et Sass en une quinzaine de lignes. Les paquets UX tiers, eux, se déclarent dans controllers.json et sont résolus depuis node_modules, exactement comme sous Encore.
L'annonce de Symfony UX 3.3.0, publiée le 15 juillet 2026, officialise cette intégration : StimulusBundle supporte désormais Reprise comme système d'assets de premier rang, au même titre qu'AssetMapper et Encore. Symboliquement, @symfony/stimulus-bridge — le pont historique spécifique à Webpack — n'est même plus une dépendance par défaut. Démarrer une application Stimulus sous Reprise tient en deux lignes :
// assets/app.js
import { startStimulusApp } from '@symfony/reprise/stimulus'
const app = startStimulusApp()
// Les contrôleurs locaux (assets/controllers/*_controller.js) sont
// enregistrés automatiquement. Pour un chargement à la demande :
//
// /* stimulusFetch: 'lazy' */
// export default class extends Controller {}Restons lucides : c'est encore un chantier
Tout n'est pas rose, et le README ne s'en cache pas : Reprise est expérimental et « susceptible de changer, voire de changer drastiquement ». Aucune release taguée à l'heure où j'écris, un RepriseBundle encore qualifié de stub dans sa propre documentation, et des issues ouvertes révélatrices — comme la #17, où les collecteurs Vite et Rsbuild génèrent des clés de manifest différentes pour un même asset importé, avec un risque de collision silencieuse côté Vite. C'est le quotidien normal d'un projet jeune, mais ça disqualifie Reprise pour votre application de production ce trimestre.
Autre point de vigilance : certains paquets UX exigent des ajustements spécifiques au bundler, comme au temps d'Encore. UX Leaflet Map, par exemple, référence un CSS pensé pour un loader Webpack et nécessite un alias vers le build CSS standard dans la config Vite. Rien d'insurmontable, mais la promesse « ça marche tout seul » ne couvre pas encore 100 % de l'écosystème. Testez paquet par paquet avant de vous engager.
Alors, AssetMapper est-il condamné ?
Non. Et je vais défendre cette position, parce qu'elle va à contre-courant du réflexe « le nouveau tue l'ancien ». AssetMapper et Reprise ne répondent pas au même besoin : ils incarnent les deux moitiés d'une même stratégie. La documentation Symfony recommande toujours AssetMapper pour les nouveaux projets, et cette recommandation reste parfaitement saine : pour une application Twig + Stimulus + Turbo — la stack LAST, soit l'immense majorité des applications Symfony —, zéro Node.js, zéro build et zéro node_modules restent un avantage opérationnel massif. CI plus simple, déploiements plus rapides, une surface de pannes en moins.
Ce que Reprise condamne, en revanche, c'est la zone grise dans laquelle AssetMapper s'était fait aspirer faute d'alternative moderne. Ces projets qui voulaient du TypeScript, du Vue ou une vraie toolchain de tests front, et qui empilaient TailwindBundle, SassBundle et scripts Babel maison pour tordre AssetMapper au-delà de son périmètre. Ceux-là ont désormais une porte de sortie officielle. Le vrai condamné de l'histoire, c'est Webpack Encore : toujours maintenu, mais son acte de succession est signé, publiquement, dans un dépôt de l'organisation Symfony.
Ma grille de lecture pour 2026-2027 :
- Application Twig + Stimulus + Turbo : AssetMapper, sans hésiter. C'est son terrain et il y excelle.
- Besoin de Vue SFC, React, TypeScript ou d'une toolchain front complète : Reprise, dès qu'il se stabilise. En attendant, le vite-bundle communautaire reste une option de transition raisonnable.
- Projet existant sous Encore qui tourne bien : pas d'urgence. Mais planifiez la migration vers Reprise plutôt que d'investir davantage dans votre config Webpack.
Ce que cette histoire dit de Symfony
Au-delà de l'outil, la trajectoire de Reprise raconte quelque chose de la maturité du projet Symfony. Une frustration communautaire exprimée en privé sur Slack, transformée en RFC publique, débattue pendant des mois, prototypée par son auteur, puis adoptée sous l'organisation officielle avec une intégration UX coordonnée dès le premier jour. Pas de Not Invented Here : plutôt que de réécrire un bundler ou de s'accrocher à Webpack par fidélité, l'équipe a accepté que l'écosystème JavaScript avait gagné cette bataille et a concentré son effort là où Symfony apporte une valeur unique — la glue, les conventions, l'expérience développeur.
Reprise n'est pas encore prêt pour vos projets clients. Mais installez-le sur un side project ce week-end : la sensation d'un HMR Vite instantané dans une application Symfony, avec vos contrôleurs Stimulus et vos composants Vue en SFC qui fonctionnent sans bricolage, donne un aperçu assez net de ce à quoi ressemblera le front Symfony des cinq prochaines années. Encore a eu droit à une belle carrière. Sa reprise s'annonce bien orchestrée.
