Journal
Frontend Webpack Encore

Webpack Encore : les réglages qui comptent vraiment

Journal du mercredi 26 août 2026, généré le 26 août à 21:44

Le socle : un webpack.config.js minimal mais complet

Encore reste une surcouche fluide au-dessus de Webpack, pensée pour éviter d'écrire soi-même une configuration Webpack complète. La base ressemble toujours à ceci :

const Encore = require('@symfony/webpack-encore');

Encore
  .setOutputPath('public/build/')
  .setPublicPath('/build')
  .addEntry('app', './assets/app.js')
  .splitEntryChunks()
  .enableSingleRuntimeChunk()
  .enableSassLoader()
  .enableVersioning(Encore.isProduction());

module.exports = Encore.getWebpackConfig();

enableSingleRuntimeChunk() n'est pas optionnel en pratique : sans lui, le runtime Webpack est dupliqué dans chaque entrée, ce qui casse le cache navigateur à chaque déploiement. C'est l'un des pièges classiques des configs copiées-collées sans être relues.

Découpage et cache long terme

splitEntryChunks() extrait automatiquement le code partagé entre plusieurs addEntry (par exemple une librairie utilisée sur deux pages). Combiné à enableVersioning(), chaque fichier généré porte un hash de contenu (app.a1b2c3.js), ce qui permet de mettre un cache HTTP quasi infini sur les assets sans risquer de servir une vieille version après déploiement.

TypeScript : deux stratégies, pas la même vitesse

  • enableBabelTypeScriptPreset() : transpile le TypeScript en JavaScript sans vérifier les types. Rapide, adapté au build local et au watch.
  • enableTypeScriptLoader() : passe par ts-loader, vérifie réellement les types, mais ralentit sensiblement le build.

Le compromis courant en 2026 reste de garder Babel pour la vitesse de build et de déléguer la vérification de types à un tsc --noEmit séparé, lancé en CI ou dans l'IDE.

Intégrité des ressources (SRI)

Si les assets sont servis depuis un CDN externe, enableIntegrityHashes(Encore.isProduction()) génère des attributs integrity sur les balises script et link, pour que le navigateur refuse un fichier corrompu ou altéré côté CDN. Peu utilisé, souvent oublié, pourtant trivial à activer.

Encore face à AssetMapper et Vite

Le framework Symfony pousse désormais AssetMapper comme option par défaut pour les projets simples : pas de build, importmaps natifs du navigateur. Pour des besoins plus lourds (bibliothèques npm complexes, code splitting fin, écosystème React/Vue existant), Encore garde tout son sens, au même titre que l'alternative Vite proposée via les composants UX de Symfony. Le critère de choix concret : si le projet dépend fortement de paquets npm avec des transformations avancées (SASS, PostCSS, TypeScript typé, polyfills ciblés), Encore ou Vite restent plus adaptés qu'AssetMapper, qui vise la simplicité plutôt que la personnalisation du pipeline.