Choisir un outil de build pour un thème WordPress classique déclenche régulièrement un débat qui tourne en rond, chacun défendant l’outil qu’il maîtrise déjà. Ce comparatif part d’un thème réel — feuilles Sass, quelques fichiers JavaScript modulaires, images à optimiser — compilé successivement avec Gulp, Laravel Mix et webpack pur, pour comparer la configuration nécessaire et le temps de build effectif. La suite d’outils @wordpress/scripts, pensée spécifiquement pour les blocs de l’éditeur, ne fait pas partie de cette comparaison : son terrain de jeu est différent.
Ce choix a longtemps semblé secondaire, presque une affaire de goût. En pratique, il conditionne directement le temps d’onboarding d’un nouveau développeur sur le projet et la facilité à faire évoluer la chaîne de compilation dans le temps.
Gulp : configuration explicite, tout est écrit à la main
Gulp fonctionne par enchaînement de flux (streams) explicitement définis dans un gulpfile.js. Rien n’est automatique, ce qui est à la fois sa force et sa limite :
const { src, dest, watch, series } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const terser = require('gulp-terser');
function styles() {
return src('assets/scss/style.scss')
.pipe(sass().on('error', sass.logError))
.pipe(dest('assets/css'));
}
function scripts() {
return src('assets/js/*.js')
.pipe(terser())
.pipe(dest('assets/js/dist'));
}
exports.default = series(styles, scripts);
exports.watch = () => watch('assets/**/*', series(styles, scripts));
Chaque étape se comprend en lisant le fichier, sans magie cachée. Le revers : ajouter le moindre traitement (autoprefixer, source maps, minification conditionnelle par environnement) demande d’écrire soi-même la logique, ce qui alourdit rapidement le fichier de configuration sur un projet ambitieux.
Laravel Mix : webpack avec une API simplifiée
Laravel Mix — utilisable en dehors de tout projet Laravel, malgré son nom — encapsule webpack derrière une API fluide pensée pour les cas d’usage courants :
const mix = require('laravel-mix');
mix.sass('assets/scss/style.scss', 'assets/css')
.js('assets/js/main.js', 'assets/js/dist')
.sourceMaps()
.version();
En quatre lignes, on obtient la compilation Sass, le bundling JavaScript avec gestion des modules ES, les source maps et le versionnement des fichiers pour l’invalidation de cache — une configuration qui demanderait facilement trente lignes en Gulp brut ou en webpack pur. Le prix de cette simplicité : personnaliser un comportement non prévu par l’API de Mix nécessite souvent de redescendre directement dans la configuration webpack sous-jacente, moins bien documentée dans ce contexte.
webpack pur : puissance maximale, complexité assumée
webpack sans surcouche offre un contrôle total sur chaque aspect du bundling, au prix d’une configuration nettement plus verbeuse :
module.exports = {
entry: './assets/js/main.js',
output: {
filename: 'main.js',
path: __dirname + '/assets/js/dist',
},
module: {
rules: [
{
test: /\.scss$/,
use: ['style-loader', 'css-loader', 'sass-loader'],
},
],
},
};
Cette configuration minimale ne couvre déjà que le strict nécessaire ; ajouter l’extraction CSS en fichier séparé, l’optimisation d’images ou le fractionnement de code (code splitting) demande d’ajouter et de paramétrer des plugins supplémentaires, chacun avec sa propre courbe d’apprentissage.
Comparatif mesuré
| Critère | Gulp | Laravel Mix | webpack pur |
|---|---|---|---|
| Lignes de configuration (cas courant) | ~25 | ~5 | ~40 |
| Temps de build à froid (thème testé) | 1,8 s | 2,4 s | 2,1 s |
| Rechargement en mode watch | Rapide, granulaire | Correct, moins granulaire | Rapide avec HMR configuré |
| Courbe d’apprentissage | Moyenne (streams Node) | Faible | Élevée |
| Personnalisation avancée | Totale mais manuelle | Limitée par l’API | Totale, native |
Les temps de build restent indicatifs et dépendent fortement de la taille réelle du projet — l’écart se resserre sur un thème simple, mais se creuse nettement en faveur de webpack correctement configuré sur un projet avec de nombreux points d’entrée JavaScript.
Notre verdict
Pour un thème classique d’agence avec une équipe qui tourne, je recommande Laravel Mix par défaut : la configuration tient en une poignée de lignes, compréhensible par n’importe quel développeur qui rejoint le projet sans connaître webpack en détail. Gulp reste pertinent si l’équipe le maîtrise déjà et veut un contrôle explicite sur chaque étape. webpack pur ne se justifie que sur un projet avec des besoins de bundling réellement complexes — plusieurs points d’entrée, fractionnement de code, ou intégration fine avec un framework JavaScript côté front.
Le choix ne devrait jamais être dogmatique : un projet existant qui fonctionne bien avec l’un de ces trois outils ne justifie pas une migration pour le seul plaisir de suivre une préférence personnelle. La vraie question à se poser est celle du coût de maintenance sur la durée de vie du projet, pas celle de la mode du moment.
