Packs Webpack Encore — stratégie assets

fastfony/webapp-webpack-encore-pack

Un webapp pack comme symfony/webapp-pack — mais bâti autour de Webpack Encore plutôt qu'AssetMapper. Posez-le sur un squelette neuf, vous obtenez une stack Symfony productive.

MIT

fastfony/tailwind-webpack-encore-pack

Le support Tailwind par-dessus le webapp-pack Webpack Encore. Chaîne de build familière, CSS utilitaire moderne, pas d'AssetMapper.

MIT

fastfony/webapp-webpack-encore-vue-sfc-pack

Compile les composants Vue single-file (.vue) via Webpack Encore. Embarque symfony/ux-vue pour monter des composants Vue directement depuis Twig — sans SPA séparée à maintenir.

Pourquoi Webpack Encore en 2026 ?

Symfony — et l'initiative Symfony UI — penche clairement vers AssetMapper comme défaut pour les nouveaux projets. Pas d'étape de build, des imports ES modules natifs, une expérience développeur allégée. C'est la voie sur laquelle le framework investit.

Pour autant, Webpack Encore alimente toujours une énorme base d'apps Symfony installées. Les équipes ont des années de savoir-faire en production : TypeScript, SCSS, front-ends React ou Vue, code splitting, bundle analysis, intégration CI. Tout cela ne disparaît pas simplement parce qu'une nouvelle recette est sortie.

Ces trois packs rendent triviale l'amorce d'une app Symfony 6.3+ neuve sur la voie Webpack Encore — en gardant la chaîne de build que votre équipe connaît déjà tout en bénéficiant du squelette Symfony moderne.

Attention — ils ne se mélangent pas

AssetMapper et Webpack Encore sont mutuellement exclusifs dans un même projet. Chacun s'attend à posséder le pipeline d'assets. Les trois packs webpack-encore déclarent un conflit Composer explicite sur symfony/asset-mapper : l'installation échouera tout de suite si AssetMapper est déjà là.

Choisissez une stratégie par app et tenez-vous-y. Migrer plus tard reste faisable, mais ce n'est pas un mouvement « on active les deux le temps de la transition ».

"conflict": {
    "symfony/asset-mapper": "*"
}

Le pour et le contre en un coup d'œil

Les deux stratégies sont valides et soutenues par l'écosystème Symfony. Choisissez celle qui colle à votre équipe et à vos ambitions front-end.

Stratégie	Pour	Contre
AssetMapper Le défaut moderne de Symfony	Aucune étape de build — pas de Node, pas de node_modules Imports ES modules natifs, feedback dev le plus rapide Aligné avec les défauts Symfony UI Moins de pièces mobiles en CI	Pré-traitement TypeScript / SCSS limité Difficile à étendre vers une SPA React ou Vue Écosystème plus jeune, moins de recettes
Webpack Encore La chaîne de build classique de Symfony	Énorme base installée, longue histoire TypeScript, SCSS, React, Vue de premier ordre Code splitting, tree-shaking, bundle analysis Intégrations CI matures	Nécessite Node et node_modules Feedback dev plus lent qu'avec les ES modules natifs Symfony UI s'en éloigne

Prêt à les essayer ?

Les trois packs sont sous licence MIT et hébergés sur GitHub. Un composer require et c'est parti.

fastfony/webapp-webpack-encore-pack fastfony/tailwind-webpack-encore-pack fastfony/webapp-webpack-encore-vue-sfc-pack