Webpack → Vite : récit d’une migration de bundler
(engineering.ab180.co)Je partage ici le récit du passage de Webpack à Vite, utilisé pendant 5 ans après le lancement du service. Il y a encore beaucoup d’imperfections, mais j’espère que vous le lirez avec plaisir.
Les points forts de Webpack et l’évolution de l’écosystème web
Webpack a été développé et maintenu au cours des 10 dernières années, avec un écosystème bien établi.
Il est utilisé dans de nombreux endroits, notamment Create React App, et prend en charge plusieurs navigateurs en regroupant les modules au format IIFE.
Cependant, en 5 ans, les fonctionnalités du service ont presque triplé, ce qui a allongé les temps de build et dégradé l’expérience de développement. Par ailleurs, les progrès de l’écosystème web ont apporté divers changements, comme la prise en charge des ES Modules.
Bundler + Native
Au cours des 1 à 2 dernières années, le bundling et le transpiling en s’appuyant sur la puissance du natif ont commencé à émerger. Des tentatives ont été faites pour dépasser les limites de traitement de JavaScript, qui fonctionne sur un seul thread.
Parmi les exemples représentatifs, on trouve esbuild, basé sur Golang, et SWC, basé sur Rust.
Première tentative : bundling avec esbuild seul
À l’époque, en tenant compte de l’écosystème, notamment de la stabilité et des plugins, il a été décidé d’utiliser un bundler basé sur esbuild. L’objectif était aussi de mesurer les performances propres à esbuild.
Après installation du package et exécution du script de build, un build qui prenait auparavant environ 210 secondes s’est terminé en seulement 2,16 secondes. Cela représentait une vitesse de build environ 100 fois plus rapide.
Cependant, l’application de Babel pour utiliser EmotionJS a ralenti le tout d’un facteur 10.
De plus, comme esbuild ne prend pas en charge le HMR, il a été jugé difficile à utiliser. Il aurait été possible d’implémenter directement le HMR, mais cela semblait demander beaucoup d’efforts, ainsi que des coûts élevés de maintenance et de gestion.
Deuxième tentative : bundling avec Vite
Le concept de Vite repose sur la séparation entre les dépendances et le code source.
Les dépendances ne changent pas après l’installation, elles sont donc pré-transpilées avec esbuild. Le code source, lui, change fréquemment, il est donc chargé en ESM. Les résultats de build sont mis en cache, ce qui permet des builds de développement rapides.
La migration a pu être menée facilement en utilisant les templates fournis par Vite. Il y a eu quelques problèmes, mais ils ont été résolus rapidement, et il a été possible d’obtenir une configuration bien plus courte et concise qu’avec Webpack.
Résultats de la migration du bundler
En mesurant le temps de build sur Netlify, on est passé d’une moyenne de 250 secondes à une moyenne de 90 secondes. Cela a été réduit à 36 % du niveau initial.
La simplification du fichier de configuration a permis aux membres de l’équipe de créer facilement des environnements de build personnalisés, améliorant ainsi leur efficacité.
Pour aller plus loin, il serait possible de remplacer la bibliothèque CSS-in-JS par une alternative sans dépendance à Babel, et d’essayer une organisation en monorepo.
Concernant l’écosystème, si SWC se stabilise, il pourra remplacer Babel, et le TypeScript Type Checker est lui aussi en cours de portage vers le natif.
Leçons retenues
- Même un travail qui semble énorme devient facile à résoudre si on le découpe en petites parties, qu’on le teste et qu’on en discute beaucoup.
- Même les outils aujourd’hui largement utilisés peuvent disparaître rapidement avec l’évolution de l’écosystème.
- Une bonne accessibilité crée un bon environnement.
3 commentaires
La vitesse d’esbuild est impressionnante.
J’avais des doutes en voyant que la page d’accueil d’esbuild mettait en avant une vitesse de 10 à 100x supérieure, mais en le voyant en vrai, c’était franchement impressionnant !
J’attends vraiment avec impatience que cette époque arrive aussi ! Je pense que développer deviendra vraiment bien plus agréable :)