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
L’équipe d’Alain Afflelou a choisi JoliCode comme référent technique pour le développement de son nouveau site internet. Ce site web-to-store incarne l’image premium de l’enseigne, met en valeur les collections et offre aux clients de nouvelles expériences et fonctionnalités telles que l’e-réservation, le store locator, le click & collect et l’essayage…
LOOK Cycle bénéficie désormais d’une nouvelle plateforme eCommerce disponible sur 70 pays et 5 langues. La base technique modulaire de Sylius permet de répondre aux exigences de LOOK Cycle en terme de catalogue, produits, tunnel d’achat, commandes, expéditions, gestion des clients et des expéditions.
Afin de soutenir le développement de son trafic, Qobuz a fait appel à JoliCode afin d’optimiser l’infrastructure technique du site et les échanges d’informations entre les composants de la plateforme. Suite à la mise en place de solution favorisant l’asynchronicité et la performance Web côté serveur, nous avons outillé la recherche de performance et…