Image de couverture : Symfony Reprise : l'intégration native des bundlers modernes dans vos projets Symfony
PHP & Frameworks

Symfony Reprise : l'intégration native des bundlers modernes dans vos projets Symfony

3 août 2026
5 min de lecture
3 vues
Sébastien Muler

Webpack Encore a rendu de bons et loyaux services — mais le front-end de 2026 mérite mieux

Pendant des années, Webpack Encore a été la réponse officielle de Symfony à la gestion des assets front-end. Il a permis à des milliers de développeurs PHP de ne pas se noyer dans la configuration Webpack, en exposant une API claire et des conventions raisonnables. Mais le paysage JavaScript a profondément changé, et une question s'est imposée naturellement : que vient-il après Encore ?

La réponse s'appelle Symfony Reprise, annoncée officiellement le 31 juillet 2026 sur le blog Symfony. Il ne s'agit pas d'un remplacement direct d'Encore, mais d'une couche d'intégration pensée pour connecter Symfony avec les bundlers modernes — Vite, Rsbuild, Rolldown, et les autres — de façon cohérente et maintenable.

Pourquoi les bundlers modernes changent la donne

Webpack était puissant, mais sa puissance avait un prix : une configuration verbeuse, des loaders à câbler manuellement pour chaque technologie (Sass, TypeScript, JSX…), et des temps de démarrage qui pouvaient décourager. C'est précisément pour masquer cette complexité qu'Encore avait été conçu.

La nouvelle génération de bundlers — Vite, esbuild, Rsbuild (basé sur Rspack), Rolldown — repose sur des cœurs natifs ultra-rapides. TypeScript, JSX et Sass fonctionnent avec peu ou pas de configuration. Le serveur de développement démarre en quelques millisecondes. L'expérience développeur est radicalement améliorée.

Parallèlement, Symfony AssetMapper est apparu comme la solution "zéro build" pour les projets qui n'ont pas besoin d'un bundler. Il est aujourd'hui le choix par défaut pour une large part des applications Symfony. Mais pour les projets qui ont de vraies exigences front-end — TypeScript, JSX, Vue, Svelte, ou simplement une base de code suffisamment volumineuse pour justifier un outillage sérieux — AssetMapper ne suffit pas.

C'est exactement ce vide que Reprise vient combler.

Ce que Symfony Reprise apporte concrètement

Reprise n'est pas un bundler. C'est une couche d'intégration : elle fait le lien entre Symfony (le système de routing, la gestion des assets, le mode debug, les environnements dev/prod) et n'importe quel bundler moderne.

Concrètement, voici ce que cela implique pour votre workflow :

  • Indépendance vis-à-vis du bundler : vous choisissez Vite aujourd'hui, vous migrez vers Rolldown demain — Reprise gère l'abstraction. Votre code Symfony n'a pas à changer.
  • Intégration des manifests d'assets : Reprise lit les fichiers de manifeste générés par les bundlers et les expose à Symfony via les fonctions Twig habituelles (asset(), versionnement, etc.).
  • Support natif du mode dev : le serveur HMR (Hot Module Replacement) de Vite, par exemple, est automatiquement détecté et relayé sans configuration manuelle.
  • DX cohérente : une seule API Symfony pour configurer l'intégration, quelle que soit la stack JS choisie.

L'objectif affiché est clair : les développeurs Symfony ne devraient pas avoir à devenir des experts en configuration Webpack — ni en configuration Vite. Reprise porte cette complexité à leur place.

Migration depuis Encore : une transition progressive

Une des premières questions que soulève Reprise est évidemment : faut-il migrer tout de suite ? La réponse de l'équipe Symfony est nuancée.

Webpack Encore continue de fonctionner. Il n'est pas déprécié, et les projets existants n'ont aucune urgence à migrer. Mais pour les nouveaux projets, ou pour ceux qui souhaitent adopter Vite ou Rsbuild, Reprise est désormais la voie recommandée.

La migration depuis Encore est conçue pour être progressive :

  1. Installer le package Reprise et configurer le bundler cible (ex. Vite)
  2. Remplacer la configuration Encore par la configuration Reprise équivalente
  3. Ajuster les points d'entrée et les imports dans vos fichiers JS/TS
  4. Supprimer Encore une fois la transition validée

Pas de réécriture brutale, pas de changement d'architecture Symfony. La courbe d'apprentissage est volontairement faible pour les équipes déjà familières avec l'écosystème.

Ce que cela change pour la maintenabilité de vos projets

Au-delà de la DX immédiate, Reprise a des implications importantes sur la maintenabilité à long terme des projets Symfony avec des besoins front-end sérieux.

L'un des problèmes récurrents avec Encore était le couplage fort à Webpack. Quand la communauté JavaScript a commencé à converger vers Vite, les projets Symfony se retrouvaient dans une position inconfortable : rester sur une stack vieillissante ou effectuer une migration risquée hors du cadre officiel.

Avec Reprise, ce problème disparaît structurellement. L'abstraction fournie par la couche d'intégration garantit que changer de bundler ne nécessite plus de modifier votre code Symfony. C'est un gain de maintenabilité considérable sur des projets à durée de vie longue — ce qui est souvent le cas dans les contextes PHP/Symfony.

C'est aussi une excellente nouvelle pour les équipes qui maintiennent plusieurs projets : une seule façon de faire, quel que soit le bundler retenu projet par projet.

Conclusion

Symfony Reprise marque une étape de maturité dans la gestion des assets front-end au sein de l'écosystème Symfony. En découplant l'intégration Symfony de tout bundler spécifique, il offre aux équipes la liberté de choisir leurs outils sans sacrifier la cohérence ni alourdir la maintenance.

Pour les projets qui n'ont pas besoin de build step, AssetMapper reste le choix naturel. Pour tous les autres, Reprise est désormais la bonne réponse — moderne, évolutive, et fidèle à la philosophie Symfony de cacher la complexité derrière une API bien pensée.

Source originale : Introducing Symfony Reprise: The Symfony Integration Layer for Modern Bundlers — Hugo Alliaume, Symfony Blog, 31 juillet 2026.

Partager cet article