Webpack : l'empaqueteur historique de l'écosystème JavaScript

Pendant près de dix ans, la question « comment mettre ce projet en production ? » avait une seule réponse sérieuse : Webpack. C'est lui qui a rendu banal d'importer une feuille de style ou une image depuis un fichier JavaScript.

Il a perdu du terrain sur les projets neufs, mais il fait encore tourner une part énorme des applications en service, et savoir le lire reste utile.

Définition

Webpack est un Bundler (empaqueteur) : il part d'un point d'entrée, suit les imports, applique une transformation à chaque type de fichier rencontré, et écrit le résultat dans un dossier de sortie. Tout se pilote depuis un fichier de configuration.

// webpack.config.js
const path = require('path');

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    filename: 'bundle.[contenthash].js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    rules: [
      { test: /\.css$/, use: ['style-loader', 'css-loader'] },
      { test: /\.js$/, exclude: /node_modules/, use: 'babel-loader' },
    ],
  },
};

Le champ mode vaut son pesant d'or : en production, Webpack active seul la Minification et le Tree shaking (élagage), là où development privilégie la lisibilité et la vitesse de reconstruction.

Loaders et plugins, deux rôles distincts

Chaque règle associe un motif de nom de fichier, écrit en RegExp, à la chaîne d'outils qui doit le traiter. Les loaders d'une même règle s'appliquent de droite à gauche, ce qui explique l'ordre inhabituel du tableau use.

Ce qui le maintient en place

Sa force reste son écosystème : des années de greffons couvrant des cas très particuliers, et une configuration capable de décrire à peu près n'importe quel pipeline. Sur une application ancienne et volumineuse, cette souplesse vaut souvent mieux qu'une réécriture.

Sa faiblesse est l'autre face de la même pièce. La configuration se lit mal, le démarrage devient long à mesure que le projet grossit, et Vite propose sur ces deux points une expérience nettement plus simple.

Questions fréquentes

Pas par principe. Une migration se justifie quand l'attente au démarrage pèse vraiment sur le travail quotidien, ou quand la configuration n'est plus comprise par personne dans l'équipe. Sur un projet stable dont le build passe en quelques secondes, l'effort se placera mieux ailleurs.

Trois causes reviennent sans cesse : un loader appliqué au dossier node_modules faute d'exclusion, une génération de Source map trop détaillée en développement, et des dépendances retraitées à chaque reconstruction. Le champ exclude et un réglage moins coûteux de devtool règlent souvent l'essentiel.

Il peut cibler Node.js plutôt que le navigateur, ce qui sert par exemple à préparer une fonction déployée chez un hébergeur. Le besoin est plus rare, puisqu'un serveur n'a pas de problème de requêtes réseau pour charger ses propres fichiers.