Optimiser webpack dans la CI
La compilation des assets avec webpack est une tâche qui prend souvent beaucoup de temps. À chaque build du projet dans la CI, il faut re-compiler ces assets, encore et encore (pun intended).
Il est possible de mettre en place du cache, pour éviter cette étape. Mais dans cet article nous voulons explorer un autre moyen de procéder.
Il existe certaines conditions où le build des assets n’est pas strictement nécessaire. Par exemple, si l’application ne possède pas de tests fonctionnels exécutant le JavaScript (avec Panther, Cypress ou Playwright par exemple).
Dans ce cas, pourquoi perdre du temps à compiler des artefacts qui ne seront pas utilisés ? Déjà, car l’application ne sera pas en mesure de démarrer si le fichier entrypoints.json
n’existe pas :
An exception has been thrown during the rendering of a template Could not find the entrypoints file from Webpack: the file « /var/www/public/build/entrypoints.json » does not exist.
Mais au fait, quel est ce fichier et à quoi sert-il ? Ce fichier est généré par webpack, pour que Symfony puisse savoir où sont compilés les fichiers que nous voulons inclure à partir de l’entrypoint. Par exemple, dans l’application, s’il y a un entrypoint app
, le fichier ressemblera à ceci :
{
"entrypoints": {
"app": {
"js": [
"/build/runtime.js",
"/build/0.js",
"/build/vendors~app.js",
"/build/app.js"
],
"css": [
"/build/vendors~app.css",
"/build/app.css"
]
}
}
}
Pour contourner ce problème, nous allons désactiver tous les plugins webpack qui ne sont pas strictement nécessaires à la compilation des assets. Pour ce faire, il faut ajouter les lignes suivantes à la fin du fichier webpack.config.js
,
const AssetsPlugin = require('assets-webpack-plugin');
const ManifestPlugin = require('webpack-manifest-plugin');
if (process.env.WEBPACK_DUMP_CONFIG) {
config.module = {};
config.plugins = config.plugins.filter((plugin) => (plugin instanceof AssetsPlugin || plugin instanceof ManifestPlugin));
}
// cette ligne existe déjà dans la configuration par défaut
module.exports = config;
Enfin, dans votre CI vous pouvez compiler vos assets avec la ligne suivante :
WEBPACK_DUMP_CONFIG=1 yarn encore dev || true
Et voilà 🎉 Grâce à ce hack, nous avons pu gagner plus de deux précieuses minutes par build ! Les développeurs ont maintenant un feedback plus rapide, la facture de CI est réduite, et on économise de l’énergie. Ces 4 petites lignes sont vraiment rapides à mettre en place, pourquoi s’en priver ?
Vous vous demandez sûrement comment cela fonctionne. En désactivant tous les plugins inutiles, webpack va quand même déplacer les assets, et générer le fichier public/build/entrypoints.json
. Rien de plus 😎
Commentaires et discussions
Ces clients ont profité de notre expertise
Pour améliorer les performances et la pertinence des recherches sur le site e-commerce, JoliCode a réalisé un audit approfondi du moteur Elasticsearch existant. Nous avons optimisé les processus d’indexation, réduisant considérablement les temps nécessaires tout en minimisant les requêtes inutiles. Nous avons également ajusté les analyses pour mieux…
En tant que joaillier 100 % numérique, l’équipe de Courbet Paris a souhaité se doter d’une plateforme eCommerce, capable d’offrir une expérience moderne qui revalorise l’acte d’achat de produits de joaillerie sur internet. JoliCode a accompagné leur équipe en développant une plateforme robuste, mais aussi évolutive, afin de répondre aux enjeux business…
Nous avons travaillé en étroite collaboration avec Cerfrance pour améliorer la qualité de leurs projets PHP et Symfony, tout en renforçant les compétences de leur équipe. Notre intervention a consisté à mettre en place une intégration continue (CI), à coacher l’équipe pour l’ajout de fixtures et de tests, à dockeriser l’application, et à installer…