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
Travailler sur un projet US présente plusieurs défis. En premier lieu : Le décalage horaire. Afin d’atténuer cet obstacle, nous avons planifié les réunions en début d’après-midi en France, ce qui permet de trouver un compromis acceptable pour les deux parties. Cette approche assure une participation optimale des deux côtés et facilite la communication…
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…
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, …