13 Punkte von xguru 2024-06-02 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Zu Beginn der Entwicklung waren die Build-Zeiten mit etwa 30 Sekunden noch akzeptabel, doch mit der schrittweisen Erweiterung der Funktionen stiegen sie auf 1 Minute und 10 Sekunden an
  • Lange Build-Zeiten verlangsamen den Entwicklungsprozess, verlängern das Onboarding neuer Entwickler und erschweren es, sich bei alltäglichen Aufgaben zu konzentrieren

Verbesserungsversuch durch einen Hackathon

  • Im Januar wurden Daten gesammelt, ein Hackathon-Projektvorschlag ausgearbeitet, das bestehende Build-System besser verstanden und nach Profiling-Methoden gesucht
  • Der gesamte Build-Prozess wurde mit OpenTelemetry und Jaeger profiliert
    • Das Profiling zeigte, dass die Ausführung von Webpack/Rollup den Großteil der Build-Zeit beanspruchte
    • Es wurde festgestellt, dass viele kleine Abhängigkeiten einzeln gebaut wurden, wodurch es viele Möglichkeiten zur Parallelisierung gab
    • Außerdem zeigte sich früh, dass einige besonders heiße Aufgaben unnötig lange dauerten und dadurch den restlichen Build-Prozess verzögerten
  • Während des Hackathons lag der Fokus darauf, die Bundling-Zeit mit esbuild zu verkürzen
    • Der Einsatz von esbuild als Loader für Webpack/Rollup brachte deutliche Leistungsverbesserungen (bei Rollup eine Verkürzung um 80 %)
    • Der Einsatz von esbuild als vollständiger Ersatz für Webpack/Rollup als Bundler verkürzte die Bundling-Zeit um 90 %
  • Das Hackathon-Projekt verkürzte die Build-Zeit der Erweiterung um mehr als 70 % auf etwa 15 Sekunden

Arbeiten für den Produktiveinsatz

  • Im Hackathon-Projekt wurden viele provisorische Lösungen verwendet, daher mussten sie für den Produktiveinsatz durch echte Lösungen ersetzt werden
    • Die Nutzung von Webpack und Rollup wurde vollständig auf esbuild umgestellt
    • Der Build-Prozess wurde an einer zentralen Stelle zusammengeführt
    • Probleme bei der Verarbeitung grafischer Assets wurden gelöst
    • TypeScript-Typprüfung wurde wieder in den Build-Prozess integriert
    • Produktions-Builds wurden getestet und hinsichtlich Größe und Funktion verglichen
    • Änderungen an internen Abhängigkeiten wurden übernommen
    • Weitere Aspekte des bisherigen Build-Systems wie der Sentry-Build-Schritt wurden nachgebildet
    • Zusätzliche Anforderungen für Nicht-Chrome-Browser, Polyfills und store-spezifische Build-Anforderungen wurden berücksichtigt
  • Die Arbeiten konzentrierten sich besonders auf Typprüfung und Optimierung der Bundle-Größe

Typprüfung zu esbuild hinzufügen

  • tsc ist langsam und daher schwer mit dem schnellen Build-Prozess von esbuild zu kombinieren
  • Mit dem Community-Plugin esbuild-plugin-typecheck wurde tsc in Worker-Threads ausgeführt und inkrementelle Kompilierung genutzt
  • Zusätzlich wurde ein einfaches eigenes Typprüfungs-Plugin implementiert, das für jedes Package-Root parallel tsc-CLI-Prozesse ausführt
    • Die diagnostischen Meldungen der tsc-Kompilierung wurden in das native Format von esbuild umgewandelt, um die Lesbarkeit zu verbessern
    • Mit dem Flag tsc --listFilesOnly und dem Metafile von esbuild wurde automatisch geprüft, ob alle Build-Eingaben typgeprüft wurden

Verbesserung der Produktions-Bundle-Größe

  • Mit dem Bundle-Größen-Analyzer von esbuild wurden die Produktions-Bundles analysiert
    • Dabei wurde entdeckt, dass sowohl ESM- als auch CJS-Builds der UI-Komponentenbibliothek im Bundle enthalten waren
    • Durch die Korrektur einer fehlerhaften Konfiguration in einer internen Bibliothek wurde die Bundle-Größe reduziert (3.3MB -> 2.1MB)
    • Die Verringerung der Dateigröße zeigte sich über mehrere Entrypoints hinweg

Auswirkungen und Fazit

  • In der Produktionsimplementierung wurden die Warm-Build-Zeiten um mehr als 90 % auf etwa 5 Sekunden verkürzt
  • Im Watch-Modus kann bei Änderungen an TypeScript-Dateien in weniger als 1 Sekunde neu gebaut werden
  • Entwickler gaben als Feedback, dass sich ihre Arbeitseffizienz durch das neue Build-System deutlich verbessert habe
  • Dank des Einsatzes des QA-Teams und freiwilliger Entwickler verlief der Umstieg auf das neue Build-System reibungslos
  • Laut einer Entwicklerzufriedenheitsumfrage sank die Unzufriedenheit mit den Build-Zeiten deutlich von 97 % auf 5 %
  • esbuild ist ein hervorragendes Tool, und Hackathon-Projekte sind für solche Arbeiten ideal

Noch keine Kommentare.

Noch keine Kommentare.