Wählen und konfigurieren Sie Build-Tools basierend auf Best Practices.
Aktualisiert
Heute startet web.dev eine neue Initiative namens tooling.report. Diese Website bietet Webentwicklern einen Überblick über die Funktionen, die von einer Auswahl beliebter Build-Tools unterstützt werden. Wir haben diese Site erstellt, um Ihnen bei der Auswahl des richtigen Build-Tools für Ihr nächstes Projekt zu helfen, zu entscheiden, ob es sich lohnt, von einem Tool auf ein anderes zu migrieren, oder um herauszufinden, wie Sie Best Practices in Ihre Codebasis und Tool-Konfiguration integrieren können. Tools haben unterschiedliche Schwerpunkte und sind auf unterschiedliche Anforderungen zugeschnitten. Dies bedeutet, dass die Auswahl und Konfiguration von Tools mit Kompromissen verbunden ist. Mit tooling.report ist es unser Ziel, diese Kompromisse zu erläutern und zu dokumentieren, wie Best Practices mit einem bestimmten Build-Tool befolgt werden.
Es klingt aufregend? Besuchen Sie tooling.report, um mit der Erkundung zu beginnen, oder lesen Sie weiter, um mehr darüber zu erfahren, warum und wie wir diese Website entwickelt haben.
Auf GoogleChromeLabshaben wir Webanwendungen wie erstellt
Squoosh y Proxxsowie Websites wie Chrome Developer Summit 2019. Wie bei jedem Webentwicklungsprojekt beginnen wir normalerweise mit der Erörterung der Infrastruktur des Projekts, z. B. der Hosting-Umgebung, der Frameworks und unserer Einstellungen für das Build-Tool. Diese Infrastruktur wird im Verlauf des Projekts aktualisiert: Neue Plugins werden hinzugefügt, um den von uns verwendeten Frameworks oder Techniken Rechnung zu tragen, oder die Art und Weise, wie wir Code schreiben, wird geändert, damit unsere Build-Tools besser verstehen, was wir erreichen wollen. 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 Benutzern das bestmögliche Web-Erlebnis zu bieten. Dies führt häufig zu einer Feinabstimmung der Zusammenstellung und Bereitstellung unserer Frontend-Assets. Wenn beispielsweise ein Haupt-Thread-Skript und ein Web-Worker-Skript gemeinsame Abhängigkeiten aufweisen, möchten wir die Abhängigkeiten einmal herunterladen, anstatt sie zweimal für jedes Skript zu bündeln. Einige Tools unterstützen dies sofort, andere erfordern einen erheblichen Anpassungsaufwand, um das Standardverhalten zu ändern, und für andere ist dies völlig unmöglich.
Diese Erfahrung veranlasste uns zu untersuchen, was verschiedene Bauwerkzeuge können und was nicht. Wir hatten die Hoffnung, eine Feature-Checkliste zu erstellen, damit wir beim nächsten Start eines neuen Projekts bewerten und auswählen können, welches Tool für unser Projekt am besten geeignet ist.
Unser Fokus
Wie können wir verschiedene Bauwerkzeuge an einem Ort bewerten und vergleichen? Wir nähern uns dem, indem wir Testfälle schreiben.
Unser Team diskutierte und entwarf Testkriterien, von denen wir glauben, dass sie Best Practices für die Webentwicklung darstellen. Wir konzentrieren uns speziell darauf, wie schnelle, reaktionsschnelle und flüssige Benutzererfahrungen erzielt werden können, wobei Tests im Zusammenhang mit der Entwicklererfahrung absichtlich ausgeschlossen werden, um zu vermeiden, dass zwei unübertroffene Ergebnisse gemessen werden.
Nachdem die Testliste erstellt wurde, haben wir für jedes Tool ein Build-Skript geschrieben, um zu überprüfen, ob das Tool die Testerfolgskriterien erfüllen kann. Zunächst haben wir uns entschlossen, Webpack v4, Rollup v2 und Parcel v2 zu untersuchen. Wir haben auch Browserify + Gulp getestet, da eine große Anzahl von Projekten diese Einstellung noch verwendet. Damit ein Test bestanden werden kann, können nur öffentlich dokumentierte Funktionen des Tools oder ein Plug-In für das Tool verwendet werden. Nach dem Schreiben der ersten Tests arbeiten wir mit den Autoren des Build-Tools zusammen, um sicherzustellen, dass wir ihre Tools korrekt verwenden und sie fair darstellen.
In vielen Teams gibt es Mitarbeiter, die sich mit der Instandhaltung der Gebäudeinfrastruktur befassen, und andere Teammitglieder können möglicherweise nie eine Entscheidung treffen, wenn es um Bauwerkzeuge geht. Wir hoffen, dass diese Website auch für Sie weiterhin nützlich ist, um Erwartungen an die Tools zu setzen, denen Sie vertrauen. Für jeden Test haben wir eine Erklärung beigefügt, warum der Test wichtig ist, sowie zusätzliche Ressourcen. Wenn Sie mit dem Tool Ihrer Wahl eine bewährte Methode anwenden möchten, enthält die Testkonfiguration in unserem Repository die erforderlichen Konfigurationsdateien.
Kann ich zur Website beitragen?
Wenn Sie der Meinung sind, dass eine derzeit fehlende Funktion getestet werden sollte, bitte Schlagen Sie es in einer GitHub-Ausgabe vor um die Diskussion zu beginnen. Unser Ziel ist es, reale Anwendungsfälle zusammenzufassen. Weitere Tests, die diese Ergebnisse besser bewerten, sind willkommen.
Wenn Sie Tests für Tools schreiben möchten, die wir nicht im Starter-Set enthalten haben, begrüßen wir das auch! Bitte schau zu
CONTRIBUTING.md für mehr Informationen.
