Une équipe interne gérait un plugin regroupant quinze blocs distincts pour un intranet d’entreprise, chacun avec son propre dossier source, tous compilés via @wordpress/scripts selon la convention standard. Le temps de build complet, initialement de quelques secondes, avait fini par dépasser la minute à chaque modification, ralentissant sensiblement le cycle de développement. La question posée en réunion technique était directe : fallait-il continuer avec l’outillage officiel, ou basculer vers une configuration Webpack entièrement personnalisée, taillée sur mesure pour ce nombre de blocs ?
Cette question revient régulièrement dès qu’un plugin dépasse une dizaine de blocs, et la réponse dépend moins d’une préférence technique que d’une évaluation honnête du coût de maintenance à long terme face au gain de contrôle recherché.
Ce que wp-scripts fait bien par défaut
Le package @wordpress/scripts encapsule une configuration Webpack déjà alignée sur les besoins standards de l’écosystème WordPress : résolution automatique des dépendances (@wordpress/element devient wp.element sans bundling inutile), génération d’un fichier .asset.php listant les dépendances et la version pour l’enregistrement côté PHP, support de Sass et de TypeScript sans configuration additionnelle.
{
"scripts": {
"build": "wp-scripts build",
"start": "wp-scripts start"
}
}Pour la grande majorité des projets, y compris ceux avec plusieurs blocs, wp-scripts détecte automatiquement chaque dossier de bloc contenant un fichier block.json et génère l’entrée de build correspondante, sans configuration manuelle de points d’entrée.
Où wp-scripts montre ses limites
La configuration par défaut reste volontairement générique, ce qui devient contraignant pour des besoins précis : un chunk JavaScript partagé entre plusieurs blocs qui utilisent un même composant lourd, un découpage plus fin entre code d’édition et code de rendu front pour réduire le poids chargé côté visiteur, ou une intégration avec un système de design tokens généré par un outil externe au pipeline standard.
Le comparatif détaillé
| Critère | @wordpress/scripts | Webpack personnalisé |
|---|---|---|
| Configuration initiale | Quasi nulle | Significative |
| Maintenance dans le temps | Suivie par l’équipe Core | À la charge de l’équipe projet |
| Code-splitting fin | Limité | Total contrôle |
| Compatibilité avec les mises à jour WordPress | Garantie par conception | À vérifier manuellement |
| Vitesse de build sur gros projet | Peut ralentir sans ajustement | Optimisable précisément |
La voie intermédiaire, souvent oubliée
Peu de documentation met en avant la possibilité d’étendre la configuration de wp-scripts plutôt que de la remplacer intégralement, via le fichier webpack.config.js à la racine du projet, qui peut importer la configuration par défaut et la fusionner avec des ajustements ciblés.
const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
module.exports = {
...defaultConfig,
optimization: {
...defaultConfig.optimization,
splitChunks: {
cacheGroups: {
composantsPartages: {
test: /[\\/]src[\\/]composants-partages[\\/]/,
name: 'composants-partages',
chunks: 'all',
},
},
},
},
};Cette approche a résolu le problème initial de l’équipe : en isolant les composants partagés entre plusieurs blocs dans un chunk commun, le temps de build est redescendu à une vingtaine de secondes, sans abandonner les garanties de compatibilité offertes par l’outillage officiel.
- Commencer systématiquement par wp-scripts, jamais l’inverse.
- N’étendre la configuration que pour un besoin précisément identifié, jamais par anticipation.
- Documenter chaque ajout à webpack.config.js pour que la prochaine personne comprenne pourquoi il existe.
Basculer vers un Webpack entièrement personnalisé transforme un problème de build en projet d’infrastructure à part entière, avec sa propre dette technique. Étendre la configuration existante résout, dans la majorité des cas, le même problème pour une fraction du coût.
Notre verdict
Pour la grande majorité des plugins, même à quinze blocs et au-delà, la configuration étendue de wp-scripts couvre l’essentiel des besoins avancés sans sacrifier les garanties de compatibilité offertes par l’outillage officiel. Une configuration Webpack entièrement personnalisée ne se justifie que pour des besoins très spécifiques, rarement rencontrés en dehors de très grandes plateformes avec une équipe dédiée à l’outillage front.
