Symfony Reprise 1.0 a été publié le 26 août 2026. Le projet fournit à Vite et Rsbuild la couche d’intégration dont une application Symfony a besoin : points d’entrée, manifests, fonctions Twig, serveur de développement, Symfony UX, CDN et Subresource Integrity. La version 1.0 retire le statut expérimental et place l’API publique sous versionnement sémantique et promesse de compatibilité Symfony. Cela en fait un candidat sérieux pour remplacer Webpack Encore, mais pas une migration automatique.
À retenir : Reprise n’est pas un nouveau bundler. Vite ou Rsbuild réalisent la compilation ; Reprise produit les fichiers et conventions attendus par Symfony. Le projet réduit la friction de migration, mais il faut encore inventorier les comportements Encore, choisir un bundler, valider les assets copiés, le développement local, Symfony UX, le cache et le déploiement.
1. Ce que stabilise réellement Reprise 1.0
La publication de Reprise 1.0 ne correspond pas à l’ajout d’une longue liste de fonctions. Elle constitue surtout un engagement de stabilité. Selon l’annonce Symfony, l’API publique suit désormais le versionnement sémantique et la promesse de compatibilité du framework : une rupture doit passer par une dépréciation avant une prochaine version majeure.
Ce point est important pour les équipes qui hésitaient à baser leur chaîne d’assets sur un composant encore présenté comme expérimental. La série de versions précédentes a surtout renforcé les tests de bout en bout, le support de l’intégrité des sous-ressources, le playground et le guide de migration depuis Encore.
La prudence reste néanmoins nécessaire. Symfony indique explicitement que Reprise est encore jeune. Une version 1.0 signifie que l’interface publique est stabilisée ; elle ne prouve pas que tous les cas particuliers rencontrés dans des années de projets Encore sont déjà couverts. Un pilote sur une application réelle reste indispensable.
2. Une couche Symfony, pas un concurrent de Vite ou Rsbuild
Webpack Encore combinait une configuration simplifiée de Webpack et une intégration étroite avec Symfony. Reprise adopte une séparation plus nette. Vite ou Rsbuild prennent en charge TypeScript, Sass, PostCSS, JSX, Vue ou Svelte, le découpage du code, les source maps, la minification et le rechargement à chaud. Reprise ne réimplémente pas ces fonctions.
Sa responsabilité est de produire et lire les conventions utiles au backend : entrypoints.json, manifest.json, résolution des fichiers hashés, fonctions Twig, connexion au serveur de développement, gestion de plusieurs builds, copie de fichiers, prise en charge de Symfony UX et ajout éventuel de hachages SRI.
Cette architecture évite de créer une abstraction complète au-dessus des bundlers. Elle permet d’utiliser leurs fonctionnalités natives tout en conservant une expérience Symfony homogène. Elle impose en contrepartie de comprendre à quel niveau se règle chaque besoin. Un alias JavaScript, un plugin Vue ou une optimisation de bundle appartient au bundler ; la génération des tags Twig et la relation au composant Asset appartiennent à Reprise.
Cette distinction doit être inscrite dans la documentation du projet afin d’éviter une configuration dispersée ou redondante.
3. Choisir entre Vite et Rsbuild
Reprise supporte Vite et Rsbuild. Le choix ne doit pas reposer uniquement sur la popularité ou un benchmark générique.
Vite bénéficie d’un écosystème très large, d’une forte adoption et d’une expérience de développement connue de nombreuses équipes frontend. Il constitue souvent le choix naturel pour des projets Vue, React, Svelte ou JavaScript classique disposant déjà de plugins Vite.
Rsbuild s’appuie sur l’écosystème Rspack et vise une compatibilité importante avec les usages issus de Webpack, avec une attention particulière aux performances de build. Il peut être intéressant lorsqu’un projet possède une configuration complexe ou des habitudes plus proches de Webpack, sous réserve de vérifier chaque plugin réellement utilisé.
Construisez un test représentatif : une entrée publique, une entrée d’administration, du Sass, quelques imports dynamiques, un contrôleur Stimulus, des assets copiés et un build de production. Comparez le temps de démarrage, le temps de compilation, la stabilité du HMR, la taille des sorties, la compatibilité des plugins et la lisibilité de la configuration.
Le meilleur bundler est celui que l’équipe sait exploiter, diagnostiquer et maintenir avec les dépendances du projet.
4. Cartographier l’existant Webpack Encore
Avant de modifier la configuration, inventoriez chaque appel Encore.* et chaque comportement indirect. Le guide officiel de Reprise fournit une correspondance méthode par méthode, ce qui facilite ce travail, mais ne remplace pas l’analyse du résultat attendu.
Relevez les points d’entrée, les chunks partagés, les fichiers statiques copiés, les alias, les variables d’environnement, les loaders spécifiques, les plugins, les polyfills, les contrôleurs Stimulus, les packages Symfony UX, les éventuels bundles multiples et les chemins utilisés par les templates ou le code PHP.
Inspectez également le déploiement : où le build est-il exécuté ? Le répertoire public/build est-il conservé entre les étapes ? Les images sont-elles envoyées vers un CDN ? Le serveur attend-il un entrypoints.json au démarrage ? Les fichiers sont-ils préchargés ou soumis à une Content Security Policy ?
Une grande partie des incidents de migration ne vient pas de la compilation du JavaScript principal, mais d’un logo copié à un chemin stable, d’un worker, d’une police, d’un fichier de traduction ou d’un script chargé par une page rarement testée.
Créez une matrice « comportement actuel / propriétaire / équivalent / test de validation ». Elle devient le contrat de migration.
5. Migrer les templates, les entrées et Symfony UX
Dans le cas courant, les helpers Twig passent de encore_entry_script_tags et encore_entry_link_tags à leurs équivalents reprise_entry_script_tags et reprise_entry_link_tags. La forme générale reste proche, mais le résultat utilise des modules ES et le fonctionnement du serveur de développement dépend du bundler choisi.
Commencez par reproduire les mêmes noms d’entrées. Cela limite les changements dans les templates et permet une comparaison page par page. Ne profitez pas de la migration pour renommer toutes les entrées, réorganiser les répertoires et refondre le JavaScript en même temps.
Pour Symfony UX et Stimulus, Reprise peut lire controllers.json et enregistrer les contrôleurs locaux ou fournis par des packages. Vérifiez cependant les besoins propres à chaque package : une feuille de style ou un asset conçu pour un loader Webpack peut nécessiter un alias ou une configuration adaptée avec Vite ou Rsbuild.
Les contrôleurs chargés de manière différée, les imports dynamiques et les composants Turbo doivent faire l’objet de tests de navigation complète. Un premier affichage correct ne garantit pas que les changements de page, les modales ou les formulaires réinitialisent correctement leur état.
Les équipes qui modernisent également leur outillage PHP peuvent rapprocher ce chantier des évolutions décrites dans notre article sur Symfony Language Tools et le LSP officiel, tout en conservant des lots indépendants pour simplifier le diagnostic.
6. Sécuriser manifests, CDN, cache et intégrité
Reprise génère un entrypoints.json et un manifest.json compatibles avec les besoins de Symfony. Vérifiez que ces fichiers sont produits dans tous les environnements et qu’ils sont présents dans l’artefact final. Une image Docker construite en plusieurs étapes peut compiler les assets puis oublier de copier le répertoire de sortie.
Les fichiers référencés directement depuis Twig ou PHP doivent être couverts par la stratégie de copie et de manifeste. Par défaut, un nom hashé facilite l’invalidation du cache. Conserver un chemin stable peut être nécessaire pour un favicon, un manifeste web ou un système externe, mais il faut alors s’assurer que le CDN ou le proxy tient compte de la chaîne de requête utilisée pour le versionnement.
Avec un CDN, le publicPath de production et le préfixe des clés du manifeste doivent correspondre. Testez l’environnement réel : origine, HTTPS, CORS, cache, compression et purge. Une URL correcte dans le fichier ne garantit pas que le fichier est effectivement publié.
Reprise peut ajouter des hachages Subresource Integrity aux scripts et feuilles de style. Cette protection est pertinente en production, mais elle doit être coordonnée avec les transformations effectuées après le build. Un CDN qui réécrit le contenu rendrait le hachage invalide.
Enfin, vérifiez les attributs nécessaires à votre Content Security Policy, notamment les nonces. Reprise expose un événement permettant de personnaliser les balises générées ; ce point doit être testé plutôt qu’ajouté après la bascule.
7. Organiser une bascule progressive
La migration la plus sûre commence par une branche dédiée et un build parallèle. Conservez temporairement la sortie Encore comme référence, puis générez la sortie Reprise dans un autre répertoire. Comparez la présence des entrées, les URLs, les assets copiés et les tailles de fichiers.
Automatisez ensuite un test de rendu des pages principales et une comparaison visuelle. Ajoutez des parcours Playwright couvrant la connexion, les formulaires, les composants interactifs, les pages d’administration et les écrans utilisant des entrées spécifiques.
Le pipeline doit exécuter le build de production, vérifier l’existence et la validité JSON des manifests, puis démarrer une application construite à partir de l’artefact final. Tester uniquement le serveur de développement ne détecte pas les oublis de copie ou les chemins de production.
Pour la mise en production, préparez un retour arrière qui restaure à la fois le code backend et les assets compatibles. Si le déploiement utilise des releases atomiques, chaque release doit embarquer son propre build afin d’éviter qu’un template ancien charge des fichiers d’une version nouvelle.
Après la bascule, surveillez les erreurs JavaScript, les réponses 404 sur les assets, les violations CSP, le cache navigateur et les temps de chargement. Ne supprimez Encore et ses fichiers de configuration qu’après une période d’observation et une recette complète.
8. Décider s’il faut migrer maintenant
Une nouvelle application Symfony peut évaluer Reprise dès le démarrage, surtout si l’équipe maîtrise déjà Vite ou Rsbuild. Le périmètre réduit du composant et la promesse de compatibilité 1.x offrent désormais une base plus prévisible.
Pour une application Encore stable, la migration doit répondre à un besoin : accélérer les builds, simplifier l’écosystème frontend, aligner plusieurs projets, réduire une configuration Webpack devenue difficile ou adopter des plugins modernes. Migrer uniquement parce qu’un outil plus récent existe crée du risque sans valeur claire.
Le niveau d’effort dépend moins du nombre de lignes de webpack.config.js que des conventions accumulées autour du build. Un projet simple peut basculer rapidement. Une plateforme multi-entrées avec CDN, workers, composants historiques et extensions sur mesure mérite un pilote complet.
Reprise 1.0 réduit l’incertitude technique. Il ne supprime pas la nécessité d’un inventaire, d’une recette et d’un plan de retour arrière.
Conclusion
Symfony Reprise 1.0 marque une étape importante pour les projets qui souhaitent utiliser Vite ou Rsbuild sans perdre l’intégration familière entre les assets et Symfony. Son choix architectural est sain : laisser le bundler compiler et fournir uniquement la couche de liaison nécessaire au framework.
Une migration réussie doit rester incrémentale. Cartographiez les comportements Encore, testez les deux bundlers sur un cas réel, reproduisez d’abord les entrées existantes, validez les manifests et le déploiement, puis seulement modernisez l’organisation du frontend. Partitech accompagne les montées de version Symfony, les migrations d’outillage et la sécurisation des chaînes de build et de déploiement.