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
Nous avons épaulé Adrenaline Hunter, juste avant le lancement public de ses offres, sur des problématiques liées à la performance de leur application développée avec Symfony. Nous avons également mis en place un système de workflow des commandes de séjours afin que toutes les actions avec leurs différents partenaires soient réparties avec fiabilité…
Notre mission a été particulièrement passionnante car Faume a pris la décision de migrer d’un modèle « agence » vers un modèle « SaaS ». Nous avons été sollicité pour challenger leur architecture actuelle basée sur Symfony et examiner leur feuille de route. Après un audit technique, nous avons identifié les principaux chantiers et scénarios…
Dans le cadre d’une refonte complète de son architecture Web, le journal en ligne Mediapart a sollicité l’expertise de JoliCode afin d’accompagner ses équipes. Mediapart.fr est un des rares journaux 100% en ligne qui n’appartient qu’à ses lecteurs qui amène un fort traffic authentifiés et donc difficilement cachable. Pour effectuer cette migration, …