Bower ist tot, lang lebe npm. Und Yarn. Und webpack.

Bower ist nicht mehr der bevorzugte Dependency-Manager für Frontend-Projekte. Das Open-Source-Projekt wird zwar weiterhin gepflegt, doch seine Entwickler haben beschlossen, es einzustellen, und erklären, wie Sie zu anderen Lösungen migrieren können – nämlich zu Yarn und webpack.

In diesem Beitrag erklären wir, warum Bower einst so gut war, nennen sechs Gründe, warum es heute nicht mehr nötig ist, und zeigen, wie Sie zu neueren und besseren Technologien wechseln.

Wofür war Bower gut?

Bower ist ein Paketmanager wie npm. Er verwaltet Frameworks, Bibliotheken, Assets und Utilities, installiert sie und hält sie auf dem neuesten Stand.

Traditionell kombinierten viele Webentwicklungsprojekte npm und Bower. npm diente zur Verwaltung von Backend-Abhängigkeiten, Bower für Frontend-Abhängigkeiten. Tatsächlich mussten Sie zunächst npm verwenden, um Bower überhaupt zu installieren.

Der größte Vorteil von Bower gegenüber npm war der flache Dependency-Graph. npm ermittelt Abhängigkeiten von Paketen und installiert möglicherweise automatisch Tausende Abhängigkeiten und Unterabhängigkeiten – darunter viele doppelte Kopien desselben Pakets. Wie Sie sich vorstellen können, ist das für Frontend-Projekte nicht ideal, da dadurch sehr umfangreiche Payloads entstehen können.

Bower überließ die Verwaltung der Abhängigkeiten hingegen den Nutzerinnen und Nutzern. Wenn beispielsweise ein Projekt viele Bibliotheken hatte, die von jQuery abhingen, konnten sie entscheiden, welche jQuery-Version installiert und als Abhängigkeit für die anderen Bibliotheken angegeben werden sollte.

Die Vorteile von Bower waren zwar überzeugend, werden inzwischen aber auch von anderen Tools geboten, nämlich npm, Yarn und webpack. Außerdem hat Bower einige deutliche Nachteile, die Sie kennen sollten.

Sechs Gründe, Bower nicht mehr zu verwenden und zu einem neuen Workflow zu wechseln

Im Folgenden finden Sie die wichtigsten Gründe, Bower für Frontend-Abhängigkeiten den Rücken zu kehren.

1. Die Entwickler haben Bower eingestellt

Nach einer langen und hitzigen Debatte auf Github entschieden die Entwickler von Bower, dass es dem aktuellen Webentwicklungs-Stack keinen Mehrwert bietet und eingestellt werden sollte. Das Open-Source-Projekt wird weiterhin gepflegt, damit bestehende Nutzerinnen und Nutzer es verwenden können. Das ist jedoch ein wichtiger Grund, die Plattform nicht weiter zu nutzen.

2. Bower bot einen flachen Dependency-Graph, den Sie jetzt auch mit npm und Yarn erhalten

npm 3 bietet einen flachen Dependency-Graph, unterstützt bei Bedarf aber auch mehrere Versionen desselben Pakets – etwas, das Bower nicht kann. Für Yarn-Nutzerinnen und -Nutzer erzielt der Befehl yarn install --flat einen ähnlichen Effekt wie Bower (siehe Yarn-CLI-Dokumentation).

3. Bower macht die Sache komplizierter und ist überflüssig, weil es npm voraussetzt

Bower benötigte npm, um ausgeführt zu werden. Eine häufig gestellte Frage lautete daher: „Warum sollte ich einen weiteren Paketmanager hinzufügen, wenn ich bereits npm habe?“

Für viele bot Bower eine nützliche Trennung zwischen Backend- und Frontend-Paketen. Diese Trennung lässt sich jedoch auch innerhalb von npm umsetzen, etwa durch das Anlegen zweier Repositories. Wer bereits npm verwendet, braucht Bower offenbar nicht.

4. Bower hat ein eigenes Paket-Ökosystem

Modulentwicklerinnen und -entwickler schätzen, dass npm allgegenwärtig ist. Da alle npm verwenden, können Sie dort Ihr neuestes Paket veröffentlichen und sicher sein, dass Ihre Nutzerinnen und Nutzer leicht darauf zugreifen können. Bis vor Kurzem mussten Entwickler von Frontend-Paketen ihr Paket jedoch sowohl auf npm als auch auf Bower veröffentlichen – das war weniger praktisch.

5. Bower überließ die Verwaltung von Abhängigkeiten den Nutzerinnen und Nutzern

Eine der besten Funktionen von npm ist, dass es automatisch alle Abhängigkeiten installiert, die von den Paketen benötigt werden, auf die Ihr Code verweist. Das ist zwar sehr praktisch, bringt aber auch Komplexität mit sich und kann zu einem gefürchteten Problem namens Dependency Hell führen.

Bower bot diese Funktion einfach nicht. Stattdessen mussten Nutzerinnen und Nutzer mühsam festlegen, welches Paket welche Abhängigkeiten benötigte. So ließen sich Abhängigkeitsprobleme vermeiden, doch es entstand viel manuelle Arbeit.

Dank der jüngsten Fortschritte bei npm und unterstützenden Technologien wie webpack und Yarn lassen sich verkettete Abhängigkeiten viel einfacher verwalten.

6. Bower unterstützt nicht mehrere Versionen desselben Pakets auf derselben Seite

Das ist zwar ein Sonderfall, kommt aber recht häufig vor. In Bower konnten Sie nicht dieselbe Bibliothek aus zwei verschiedenen Paketen in zwei unterschiedlichen Versionen referenzieren. npm 3 bietet diese Möglichkeit standardmäßig und zugleich einen flachen Dependency-Graph.

Wie werden Pakete heute verwaltet?

Wir haben erwähnt, dass neuere Tools die Vorteile von Bower inzwischen überflüssig gemacht haben. Der moderne Dependency-Stack besteht aus npm/Yarn für die Verwaltung von Node-Paketen und webpack für die Verwaltung statischer Assets. Damit wird Bower überflüssig:

• npm ist der bevorzugte Paketmanager für Backend- und Frontend-Pakete.

• Yarn ist ein Frontend für npm und bietet mehrere wichtige Vorteile: schnellere Installation von Abhängigkeiten, zuverlässigeres Sperren oder Fixieren von Paketen auf eine bestimmte Version, mehr Sicherheit und einen Offline-Modus. Seit der Veröffentlichung von npm 3 sind einige dieser Vorteile weniger ausgeprägt. Prüfen Sie daher genau, ob Yarn Ihren Workflow verbessert.

• webpack ist ein Modul-Bundler, also ein Build-Tool. Mit Loadern und Plugins können Sie statische Dateiabhängigkeiten für Ihre Webprojekte vorbereiten. webpack kann beispielsweise mehrere CSS-Dateien verkleinern und als Teil Ihres Projekts erstellen. webpack ergänzt eine wichtige Funktion, die npm-Nutzerinnen und -Nutzern fehlt: Viele Assets, die für die Entwicklung einer Web-App benötigt werden, sind keine Node.js-Komponenten. webpack kann diese weiteren Elemente einbinden, vorbereiten und installieren, während npm die in der Web-App verwendeten Node-Bibliotheken installiert.

Es gibt bereits einige hervorragende Ressourcen zur Migration von Bower zu einem moderneren und vielseitigeren Stack, darunter Anrejs Abrickis’ ausführlicher Beitrag und den offiziellen Beitrag von Adam Stankiewicz, dem Ersteller von Bower.

Fazit

Angesichts des Labyrinths aus Frontend-Bibliotheken und Frameworks, die heute verfügbar sind, ist ein Paketmanager zur Verwaltung Ihrer Frontend-Abhängigkeiten unverzichtbar.

Bower spielte eine wichtige Rolle dabei, die Verwaltung von Abhängigkeiten für Frontend-Entwicklerinnen und -Entwickler zu verbessern. Seine Vorteile ebneten den Weg für spätere Funktionen in npm und Yarn. Doch Bower ist nicht mehr die beste Lösung. Mit Yarn und den Änderungen in npm 3 erhalten Sie alle Vorteile von Bower – ganz ohne Aufwand.

Die Migration zu npm oder Yarn vereinfacht Ihren Entwicklungsprozess erheblich. Dank der heutigen Tools lässt sich die riesige Auswahl an Frontend-Komponenten einfacher denn je überblicken.