Les grandes librairies et frameworks d’aujourd’hui utilisent webpack. Et on peut se demander, à juste titre, si c’est pertinent, ou si ça ne serait pas un effet de mode.
Or, lors d’un de nos derniers articles nous parlions de la venue d’un petit dernier : FuseBox, qui se veut beaucoup plus simple à configurer (et à priori plus rapide dans la phase de génération des fichiers).
Ne partons pas tout de suite de WebPack : il vaut quand même bien le coup, et nous allons voir pourquoi dans un tour du propriétaire ! 
Note: vous pouvez aller voir notre github avec plein d’exemple sur webpack, fusebox, et bientôt aussi, nodejs.
1. Une configuration rapide à mettre en place
Pour mettre en place webpack, rien de plus simple.
- Un npm init
- Un npm install webpack
- Et l’ajout d’un fichier de configuration js et le tour est joué !
Exemple de fichier webpack de configuration (par défaut) :
const path = require(‘path’);
module.exports = {
entry: ‘./src/index.js’,
output: {
filename: ‘maino.js’,
path: path.resolve(__dirname, ‘disto’),
},
};
2. Un fonctionnement super efficace avec les loaders
Le système de loader est d’une efficacité impressionnante.
Prenons par exemple le loader pour appeler babel : babel-loader.
Il suffit de l’installer avec npm install, puis de l’appeler dans notre webpack config, et hop, on a un système qui transpile notre js dernière version dans la version que l’on souhaite ! 
module: {
rules: [
{
test: /\.js$/,
exclude: /(node_modules|bower_components)/,
use: [
‘babel-loader’
]
},
Comme vous pouvez le voir, on peut même exclure des fichiers, des dossiers de la transpilation.
En plus, pour la plupart des plugins, la documentation est vraiment bien faite, plus qu’à suivre les exemples et lire en détails les exemples et on s’en sort bien !
2.1 Une prise en compte du chargement relatif des images
Vous avez un fichier css que vous souhaitez mettre en place avec l’appel d’image et le tout gérer directement par un générateur (de page html automatique, comme HtmlWebpackPlugin) ?
Mettons par exemple que vous ayez besoin d’appeler dynamiquement une image depuis votre css, hors vous souhaitez que tout soit gérer par webpack, comment faire ?
- Vous utiliser deux modules :
- Le loader css-loader qui va transformer votre css lu en une chaine
- Le loader style-loader qui va être capable de le charger à chaud sur votre page dynamique
- Le loader url-loader qui va permettre de gérer les urls relatives dynamiques
Et le tour est joué !
Un exemple de paramétrage du loader d’images :
{
test: /\.(png|jpg|gif)$/i,
use: [
{
loader: ‘url-loader’,
options: {
limit: 8192,
},
},
],
},
2.2 Une gestion des sources map presque automatique
Vous en avez marre de debugger à coup de console.log ?
Il existe une solution : le debuggage depuis le chrome dev tool.
En gros, l’idée ici est de debuggé votre fichier javascript directement depuis votre navigateur Chrome !
Pour que cela soit encore plus propre, pensez à utiliser les sourceMaps (et à les activer dans les paramétrages du Chrome dev tools).
Avec WebPack 4, c’est juste une option de la configuration initiale !
Plus qu’à choisir le type de sourceMap que vous souhaitez activer et le tour est joué !
devtool: ‘inline-source-map’,
3. Un système de chargement des package en mode différé efficace
Vous avez un package qui est trop lourd à charger dès le début de l’affichage de votre page ? Pensez plutôt au chargement à chaud !
L’idée, c’est d’importer votre package uniquement quand vous en avez besoin.
En somme c’est un appel au package, appel qui est packagé dans un fichier javascript généré par webpack. Et du côté code d’appel, on a juste à faire un import du package et de gérer une Promise en retour !
import(/* webpackChunkName: « jquery » */ ‘jquery’).then((jQuery) => {
window.$ = jQuery.default;
});
4. Des plugins nombreux et très pratiques
Vous en avez par exemple marre que lors de la génération des fichiers il ne supprime pas tous les fichiers avant nouvelle génération ? Il existe un plugin pour ça MossierDame !
Utilisez le CleanWebpackPlugin !
Et l’on peut appliquer ce raisonnement pour quasi tous les besoins que l’on a !
5. Un nouveau système des configurations dev / prod très pratique et propre
Et je finirai par une gestion des configurations dev / prod qui est juste délicieuse !
En version 3, on gérer ça à coup de NODE_ENV, c’était déjà pas mal bien fait, mais maintenant on peut encore mieux faire (enfin c’est préconise maintenant sur la doc officielle) :
Avoir un fichier de configuration par environnement : webpack.config.dev, webpack.config.prod, …
Tout ça grâce à un outil (un package) webpack-merge.
Voici ce que ça donne avec notre environnement de production :
const merge = require(‘webpack-merge’);
const configDefault = require(‘./webpack.config’);
module.exports = merge(configDefault, {
mode: ‘production’,
devtool: ‘source-map’
});
Il suffit alors de le configurer depuis notre package.json :
« scripts »: {
« dev »: « webpack –config=webpack.config.dev.js »,
« prod »: « webpack –config=webpack.config.prod.js »
},
Et vous, vous l’utilisez bien webpack ?