Auswahl und Konfiguration von Build-Tools anhand von Best Practices
Heute startet web.dev eine neue Initiative namens tooling.report. Es ist eine Website, die Webentwicklern einen Überblick über die von verschiedenen beliebten Build-Tools unterstützten Funktionen bietet. Wir haben diese Website erstellt, damit Sie das richtige Build-Tool für Ihr nächstes Projekt auswählen, entscheiden können, ob sich die Migration von einem Tool zu einem anderen lohnt oder wie Sie Best Practices in Ihre Toolkonfiguration und Codebasis einbinden können. Tools haben unterschiedliche Schwerpunkte und erfüllen unterschiedliche Anforderungen. Daher müssen bei der Auswahl und Konfiguration von Tools Kompromisse eingehen. Mit Tooling.report möchten wir diese Vor- und Nachteile erklären und dokumentieren, wie die Best Practices für ein bestimmtes Build-Tool eingehalten werden.
Klingt spannend? Rufen Sie tooling.report auf, um mehr darüber zu erfahren, oder lesen Sie weiter, um zu erfahren, warum und wie wir diese Website entwickelt haben.
Entwicklungstools stehen uns oft im Weg
Bei GoogleChromeLabs haben wir Webanwendungen wie Squoosh und Proxx sowie Websites wie die vom Chrome Dev Summit 2019 entwickelt. Wie bei jedem Webentwicklungsprojekt beginnen wir im Allgemeinen mit der Projektinfrastruktur wie der Hosting-Umgebung, Frameworks und der Einrichtung unseres Build-Tools. Diese Infrastruktur wird im Laufe des Projekts aktualisiert: Es werden neue Plug-ins hinzugefügt, um von uns übernommene Frameworks oder Techniken zu berücksichtigen, oder die Art und Weise, wie wir Code schreiben, ändert sich, sodass unsere Build-Tools besser verstehen, was wir erreichen möchten. Während dieses Prozesses haben wir oft festgestellt, dass die von uns ausgewählten Tools uns im Weg stehen.
Unser Team konzentriert sich darauf, den Nutzern eine optimale Weberfahrung zu bieten. Dies führt oft zu einer Optimierung der Zusammenstellung und Bereitstellung unserer Front-End-Assets. Wenn beispielsweise ein Hauptthread-Skript und ein Web-Worker-Skript gemeinsame Abhängigkeiten haben, möchten wir die Abhängigkeiten einmal herunterladen, anstatt sie für jedes Skript zweimal zu bündeln. Einige Tools unterstützen dies standardmäßig, andere erfordern einen erheblichen Anpassungsaufwand, um das Standardverhalten zu ändern, und bei anderen ist das völlig unmöglich.
Diese Erfahrung hat uns veranlasst, zu untersuchen, was verschiedene Build-Tools tun können und was nicht. Wir hofften, eine Checkliste für Features zu erstellen, damit wir beim nächsten Start eines neuen Projekts bewerten und das Tool auswählen können, das am besten für unser Projekt geeignet ist.
Unser Ansatz
Wie können wir verschiedene Build-Tools an einem Ort bewerten und vergleichen? Dazu haben wir Testfälle geschrieben.
Unser Team hat Testkriterien erörtert und erarbeitet, die unserer Meinung nach Best Practices für die Webentwicklung darstellen. Wir haben uns insbesondere darauf konzentriert, eine schnelle, reaktionsschnelle und reibungslose Nutzererfahrung zu bieten. Tests, die sich auf die Nutzerfreundlichkeit beziehen, wurden bewusst ausgeschlossen, um zu vermeiden, dass zwei unvergleichliche Ergebnisse gemessen werden.
Nachdem die Testliste erstellt wurde, haben wir ein Build-Skript für jedes Tool geschrieben, um zu prüfen, ob das Tool die Erfolgskriterien des Tests erfüllen kann. Als Erstes haben wir uns entschieden, Webpack v4, Rollup v2 und Parcel v2 zu untersuchen. Außerdem haben wir Browserify und Gulp getestet, da diese Konfiguration noch von einer großen Anzahl von Projekten verwendet wird. Damit ein Test bestanden wird, dürfen nur öffentlich dokumentierte Funktionen des Tools oder ein Plug-in für das Tool verwendet werden. Nachdem die ersten Tests geschrieben wurden, haben wir mit den Autoren des Build-Tools zusammengearbeitet, um sicherzustellen, dass wir ihre Tools korrekt eingesetzt und fair dargestellt haben.
Wir verwenden nur ${tool_name}. Ist das trotzdem wichtig?
In vielen Teams gibt es Personen, die sich um die Wartung der Build-Infrastruktur kümmern, und andere Mitglieder des Teams können möglicherweise nie eine Entscheidung treffen, wenn es um die Erstellung von Tools geht. Wir hoffen, dass diese Website auch für Sie nützlich ist, um Erwartungen an die Tools zu setzen, auf die Sie sich verlassen. Für jeden Test finden Sie eine Erklärung, warum der Test wichtig ist, sowie zusätzliche Ressourcen. Wenn Sie eine Best Practice mit dem Tool Ihrer Wahl übernehmen möchten, enthält die Testeinrichtung in unserem Repository die dafür erforderlichen Konfigurationsdateien.
Kann ich zur Website beitragen?
Wenn Sie der Meinung sind, dass eine bestimmte Funktion getestet werden sollte, die derzeit noch fehlt, schlagen Sie sie bitte in einem GitHub-Problem vor, um mit der Diskussion zu beginnen. Unser Ziel ist es, Anwendungsfälle aus der Praxis einzubeziehen. Zusätzliche Tests, mit denen diese Ergebnisse besser bewertet werden, sind willkommen.
Wir würden uns auch freuen, wenn Sie Tests für Tools schreiben möchten, die nicht im ersten Set enthalten waren. Weitere Informationen finden Sie unter CONTRIBUTING.md.