- Au début du développement, le temps de build était acceptable, autour de 30 secondes, mais il est monté progressivement à 1 minute 10 à mesure que des fonctionnalités ont été ajoutées
- Des temps de build longs ralentissaient le processus de développement, allongeaient le temps d’onboarding des nouveaux développeurs et rendaient plus difficile le maintien de la concentration dans les tâches quotidiennes
Tentative d’amélioration via un hackathon
- En janvier, l’équipe a collecté des données, rédigé une proposition de projet de hackathon, approfondi sa compréhension du système de build existant et étudié des méthodes de profiling
- L’ensemble du processus de build a été profilé à l’aide d’OpenTelemetry et de Jaeger
- Les résultats du profiling ont montré que l’exécution de Webpack/Rollup représentait la majeure partie du temps de build
- L’équipe a constaté que de petites dépendances étaient construites une par une, ce qui offrait de nombreuses possibilités de parallélisation
- Elle a aussi confirmé qu’au départ, certaines tâches critiques prenaient plus de temps que nécessaire et retardaient le reste du processus de build
- Pendant le hackathon, l’équipe s’est concentrée sur la réduction du temps de bundling avec esbuild
- L’utilisation de esbuild comme loader pour Webpack/Rollup a fortement amélioré les performances (80 % de réduction dans le cas de Rollup)
- En utilisant esbuild comme bundler remplaçant complètement Webpack/Rollup, le temps de bundling a été réduit de 90 %
- Le projet de hackathon a permis de réduire de plus de 70 % le temps de build de l’extension, pour atteindre environ 15 secondes
Travaux pour une mise en production
- Le projet de hackathon reposait sur de nombreux contournements temporaires, qui ont dû être remplacés par une vraie solution pour un déploiement en production
- Passage complet de Webpack et Rollup à esbuild
- Centralisation du processus de build en un seul endroit
- Résolution des problèmes liés au traitement des assets graphiques
- Réintégration de la vérification de types TypeScript dans le processus de build
- Tests des builds de production et comparaison de leur taille et de leurs fonctionnalités
- Prise en compte des changements dans les dépendances internes
- Reproduction d’autres aspects de l’ancien système de build, comme l’étape de build Sentry
- Ajout de la gestion des navigateurs non Chrome, des polyfills et des exigences de build propres à chaque store
- Le travail s’est concentré sur la vérification de types et l’optimisation de la taille des bundles
Ajout de la vérification de types à esbuild
tsc étant lent, il est difficile de l’utiliser avec le processus de build rapide de esbuild- Le plugin communautaire
esbuild-plugin-typecheck a été utilisé pour exécuter tsc dans un worker thread et tirer parti de la compilation incrémentale
- L’équipe a aussi implémenté son propre plugin simple de vérification de types, qui exécute en parallèle des processus CLI
tsc à la racine de chaque package
- Les diagnostics de compilation de
tsc ont été convertis au format natif de esbuild pour améliorer la lisibilité
- Le flag
tsc --listFilesOnly et le Metafile de esbuild ont été utilisés pour vérifier automatiquement que toutes les entrées du build étaient bien couvertes par la vérification de types
Amélioration de la taille des bundles de production
- L’analyseur de taille de bundle de esbuild a été utilisé pour examiner les bundles de production
- Découverte d’un problème où les builds ESM et CJS de la bibliothèque de composants UI étaient tous deux inclus dans le bundle
- Correction d’une mauvaise configuration dans une bibliothèque interne, ce qui a réduit la taille du bundle (3.3MB -> 2.1MB)
- Confirmation d’une réduction de taille sur plusieurs entry points
Impact et conclusion
- En production, l’implémentation a réduit le temps de build à chaud de plus de 90 %, pour atteindre environ 5 secondes
- En mode watch, une modification d’un fichier TypeScript peut être reconstruite en moins d’une seconde
- Les développeurs ont indiqué que le nouveau système de build avait considérablement amélioré leur efficacité au travail
- Grâce aux efforts de l’équipe QA et de développeurs volontaires, la transition vers le nouveau système de build s’est faite sans heurts
- Une enquête de satisfaction auprès des développeurs a montré que l’insatisfaction liée au temps de build est passée de 97 % à 5 %
- esbuild est un excellent outil, et les projets de hackathon sont idéaux pour ce type de travail
Aucun commentaire pour le moment.