Was ist der Unterschied zwischen Bower und npm?

Was ist der grundlegende Unterschied zwischen bowerund npm? Ich will nur etwas Schlichtes und Einfaches. Ich habe einige meiner Kollegen Gebrauch gesehen bowerund npmaustauschbar in ihrer Projekte.

Alle Paketmanager haben viele Nachteile. Sie müssen nur auswählen, mit wem Sie leben können.

Geschichte

npm begann mit der Verwaltung von node.js-Modulen (aus diesem Grund werden node_modulesstandardmäßig Pakete verwendet ), funktioniert jedoch auch für das Front-End, wenn es mit Browserify oder Webpack kombiniert wird .

Bower wurde ausschließlich für das Frontend erstellt und ist in diesem Sinne optimiert.

Größe des Repos

npm ist viel, viel größer als bower, einschließlich JavaScript country-datafür allgemeine Zwecke (z. B. für Länderinformationen oder sortszum Sortieren von Funktionen, die im Front-End oder im Back-End verwendet werden können).

Bower hat eine viel geringere Anzahl von Paketen.

Umgang mit Stilen usw.

Bower enthält Stile usw.

npm konzentriert sich auf JavaScript. Stile werden entweder separat heruntergeladen oder von so etwas benötigtnpm-sass oder benötigt sass-npm.

Abhängigkeitsbehandlung

Der größte Unterschied besteht darin, dass npm verschachtelte Abhängigkeiten ausführt ( standardmäßig jedoch flach ist), während Bower einen flachen Abhängigkeitsbaum benötigt (dies belastet den Benutzer mit der Auflösung der Abhängigkeit). .

Ein verschachtelter Abhängigkeitsbaum bedeutet, dass Ihre Abhängigkeiten ihre eigenen Abhängigkeiten haben können, die ihre eigenen haben können, und so weiter. Auf diese Weise können zwei Module unterschiedliche Versionen derselben Abhängigkeit erfordern und weiterhin funktionieren. Beachten Sie, dass der Abhängigkeitsbaum seit npm v3 standardmäßig flach ist (Platz spart) und nur dort verschachtelt wird, wo dies erforderlich ist, z. B. wenn zwei Abhängigkeiten eine eigene Version von Underscore benötigen.

Einige Projekte verwenden beides, indem sie Bower für Front-End-Pakete und npm für Entwicklertools wie Yeoman, Grunt, Gulp, JSHint, CoffeeScript usw. verwenden.

Ressourcen

• Verschachtelte Abhängigkeiten - Einblick, warum node_modules so funktioniert, wie es funktioniert

Diese Antwort ist eine Ergänzung zur Antwort von Sindre Sorhus. Der Hauptunterschied zwischen npm und Bower besteht darin, wie sie rekursive Abhängigkeiten behandeln. Beachten Sie, dass sie zusammen in einem einzelnen Projekt verwendet werden können.

Auf der npm FAQ : (archive.org Link vom 6. September 2015)

Es ist viel schwieriger, Abhängigkeitskonflikte zu vermeiden, ohne Abhängigkeiten zu verschachteln. Dies ist von grundlegender Bedeutung für die Funktionsweise von npm und hat sich als äußerst erfolgreicher Ansatz erwiesen.

Auf der Bower- Homepage:

Bower ist für das Frontend optimiert. Bower verwendet einen flachen Abhängigkeitsbaum, der nur eine Version für jedes Paket benötigt, wodurch die Seitenlast auf ein Minimum reduziert wird.

Kurz gesagt, npm strebt nach Stabilität. Bower strebt eine minimale Ressourcenbelastung an. Wenn Sie die Abhängigkeitsstruktur zeichnen, sehen Sie Folgendes:

npm:

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Wie Sie sehen, werden einige Abhängigkeiten rekursiv installiert. Abhängigkeit A hat drei installierte Instanzen!

Laube:

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Hier sehen Sie, dass sich alle eindeutigen Abhängigkeiten auf derselben Ebene befinden.

Warum also npm verwenden?

Möglicherweise erfordert Abhängigkeit B eine andere Version von Abhängigkeit A als Abhängigkeit C. npm installiert beide Versionen dieser Abhängigkeit, sodass sie trotzdem funktioniert, aber Bower führt zu einem Konflikt weil es keine Duplizierung mag (weil das Laden derselben Ressource auf eine Webseite ist sehr ineffizient und kostspielig, es kann auch einige schwerwiegende Fehler geben). Sie müssen manuell auswählen, welche Version Sie installieren möchten. Dies kann dazu führen, dass eine der Abhängigkeiten unterbrochen wird. Dies müssen Sie jedoch trotzdem beheben.

Die übliche Verwendung ist also Bower für die Pakete, die Sie auf Ihren Webseiten veröffentlichen möchten (z. B. Laufzeit , wo Sie Doppelarbeit vermeiden), und npm für andere Dinge wie Testen, Erstellen, Optimieren, Überprüfen usw. (z. B. Entwicklungszeit) , wo die Vervielfältigung weniger wichtig ist).

Update für npm 3:

npm 3 macht die Dinge immer noch anders als Bower. Die Abhängigkeiten werden global installiert, jedoch nur für die erste Version, auf die sie stoßen. Die anderen Versionen werden in der Baumstruktur installiert (das übergeordnete Modul, dann node_modules).

• [node_modules]
  • dep A v1.0
  • dep B v1.0
    • dep A v1.0 (verwendet Root-Version)
  • dep C v1.0
    • dep A v2.0 (Diese Version unterscheidet sich von der Root-Version, daher handelt es sich um eine verschachtelte Installation.)

Für weitere Informationen empfehle ich, die Dokumente von npm 3 zu lesen

TL; DR: Der größte Unterschied im täglichen Gebrauch sind nicht verschachtelte Abhängigkeiten ... es ist der Unterschied zwischen Modulen und globalen.

Ich denke, die vorherigen Poster haben einige der grundlegenden Unterschiede gut abgedeckt. (Die Verwendung verschachtelter Abhängigkeiten durch npm ist in der Tat sehr hilfreich bei der Verwaltung großer, komplexer Anwendungen, obwohl ich nicht denke, dass dies die wichtigste Unterscheidung ist.)

Ich bin jedoch überrascht, dass niemand einen der grundlegendsten Unterschiede zwischen Bower und npm explizit erklärt hat. Wenn Sie die obigen Antworten lesen, wird das Wort "Module" häufig im Zusammenhang mit npm verwendet. Aber es wird beiläufig erwähnt, als ob es nur ein Syntaxunterschied wäre.

Diese Unterscheidung zwischen Modulen und Globalen (oder Modulen und Skripten) ist jedoch möglicherweise der wichtigste Unterschied zwischen Bower und npm. Der npm-Ansatz, alles in Module zu integrieren, erfordert, dass Sie die Art und Weise, wie Sie Javascript für den Browser schreiben, mit ziemlicher Sicherheit zum Besseren ändern.

Der Bower-Ansatz: Globale Ressourcen wie <script>Tags

Bei root geht es bei Bower darum, einfache alte Skriptdateien zu laden. Was auch immer diese Skriptdateien enthalten, Bower lädt sie. Was im Grunde bedeutet , dass Bower ist genau wie mit allen Ihren Skripte in Klar alten <script>‚s in denen <head>Ihren HTML.

Der gleiche grundlegende Ansatz, den Sie gewohnt sind, aber Sie erhalten einige nette Automatisierungskomfort:

• Früher mussten Sie JS-Abhängigkeiten (während der Entwicklung) in Ihr Projekt-Repo aufnehmen oder über CDN abrufen. Jetzt können Sie dieses zusätzliche Downloadgewicht im Repo überspringen, und jemand kann schnell bower installund sofort das tun , was er vor Ort benötigt.
• Wenn eine Bower-Abhängigkeit dann ihre eigenen Abhängigkeiten in ihrer angibt bower.json angibt, werden diese auch für Sie heruntergeladen.

Aber darüber hinaus ändert Bower nichts daran, wie wir Javascript schreiben . An den von Bower geladenen Dateien muss sich nichts ändern. Dies bedeutet insbesondere, dass die Ressourcen, die in von Bower geladenen Skripten bereitgestellt werden (normalerweise, aber nicht immer), weiterhin als definiert sind globale Variablen werden , die von überall im Kontext der Browserausführung verfügbar sind.

Der npm-Ansatz: Allgemeine JS-Module, explizite Abhängigkeitsinjektion

Der gesamte Code im Knotenland (und damit der gesamte über npm geladene Code) ist als Module strukturiert (insbesondere als Implementierung des CommonJS-Modulformats oder jetzt als ES6-Modul). Wenn Sie also NPM verwenden, um browserbezogene Abhängigkeiten zu behandeln (über Browserify oder etwas anderes, das denselben Job ausführt), strukturieren Sie Ihren Code auf dieselbe Weise wie Node.

Klügere Leute als ich haben die Frage "Warum Module?" In Angriff genommen, aber hier ist eine Zusammenfassung der Kapseln:

• Alles in einem Modul hat einen effektiven Namespace , was bedeutet, dass es keine globale Variable mehr ist und Sie nicht versehentlich darauf verweisen können, ohne dies zu beabsichtigen.
• Alles in einem Modul muss absichtlich in einen bestimmten Kontext (normalerweise ein anderes Modul) eingefügt werden, um es nutzen zu können
• Dies bedeutet, dass Sie in verschiedenen Teilen Ihrer Anwendung mehrere Versionen derselben externen Abhängigkeit (beispielsweise lodash) haben können, die nicht kollidieren / in Konflikt geraten. (Dies passiert überraschend oft, weil Ihr eigener Code eine Version einer Abhängigkeit verwenden möchte, eine Ihrer externen Abhängigkeiten jedoch eine andere angibt, die in Konflikt steht. Oder Sie haben zwei externe Abhängigkeiten, die jeweils eine andere Version wünschen.)
• Da alle Abhängigkeiten manuell in ein bestimmtes Modul eingefügt werden, ist es sehr einfach, über sie nachzudenken. Sie wissen sicher: "Der einzige Code, den ich berücksichtigen muss, wenn ich daran arbeite, ist der, den ich absichtlich hier injiziert habe." .
• Da selbst der Inhalt injizierter Module hinter der Variablen, der Sie sie zuweisen, gekapselt ist und der gesamte Code in einem begrenzten Bereich ausgeführt wird, sind Überraschungen und Kollisionen sehr unwahrscheinlich. Es ist sehr viel weniger wahrscheinlich, dass etwas aus einer Ihrer Abhängigkeiten versehentlich eine globale Variable neu definiert, ohne dass Sie es merken, oder dass Sie dies tun. (Es kann passieren, aber normalerweise müssen Sie sich mit so etwas wie Mühe geben window.variable. Der einzige Unfall, der immer noch auftritt, ist das Zuweisen this.variable, ohne zu bemerken, dass dies thistatsächlich der Fall istwindow um den aktuellen Kontext handelt.)
• Wenn Sie ein einzelnes Modul testen möchten, können Sie ganz einfach wissen: Was genau (Abhängigkeiten) beeinflusst den Code, der im Modul ausgeführt wird? Und weil Sie explizit alles einfügen, können Sie diese Abhängigkeiten leicht verspotten.

Für mich läuft die Verwendung von Modulen für Front-End-Code darauf hinaus, in einem viel engeren Kontext zu arbeiten, der einfacher zu überlegen und zu testen ist, und mehr Sicherheit darüber zu haben, was vor sich geht.

Das Erlernen der Verwendung der CommonJS / Node-Modulsyntax dauert nur etwa 30 Sekunden. In einer bestimmten JS-Datei, die ein Modul sein wird, deklarieren Sie zunächst alle externen Abhängigkeiten, die Sie verwenden möchten, wie folgt:

var React = require('react');

Innerhalb der Datei / des Moduls tun Sie, was Sie normalerweise tun würden, und erstellen ein Objekt oder eine Funktion, die Sie externen Benutzern zur Verfügung stellen möchten, und rufen sie möglicherweise auf myModule .

Am Ende einer Datei exportieren Sie alles, was Sie mit der Welt teilen möchten, wie folgt:

module.exports = myModule;

Um einen CommonJS-basierten Workflow im Browser zu verwenden, verwenden Sie Tools wie Browserify, um alle diese einzelnen Moduldateien abzurufen, ihren Inhalt zur Laufzeit zu kapseln und sie nach Bedarf ineinander zu injizieren.

UND da ES6-Module (die Sie wahrscheinlich mit Babel oder ähnlichem auf ES5 übertragen werden) breite Akzeptanz finden und sowohl im Browser als auch in Node 4.0 funktionieren, sollten wir einen guten Überblick erwähnen über diese .

Weitere Informationen zu Mustern für die Arbeit mit Modulen in diesem Deck .

BEARBEITEN (Februar 2017): Facebooks Garn ist heutzutage ein sehr wichtiger potenzieller Ersatz / eine wichtige Ergänzung für npm: schnelles, deterministisches Offline-Paketmanagement, das auf dem aufbaut, was npm Ihnen bietet. Es ist einen Blick wert für jedes JS-Projekt, zumal es so einfach ist, es ein- und auszutauschen.

EDIT (Mai 2019) "Bower ist endgültig veraltet . Ende der Geschichte." (h / t: @DanDascalescu, unten, für eine markige Zusammenfassung.)

Und während Yarn noch aktiv ist , verlagerte sich ein Großteil der Dynamik auf npm zurück, sobald einige der Hauptmerkmale von Yarn übernommen wurden.

2017-Okt Update

Bower ist endgültig veraltet . Ende der Geschichte.

Ältere Antwort

Von Mattias Petter Johansson, JavaScript-Entwickler bei Spotify :

In fast allen Fällen ist es besser, Browserify und npm über Bower zu verwenden. Es ist einfach eine bessere Verpackungslösung für Front-End-Apps als Bower. Bei Spotify verwenden wir npm, um ganze Webmodule (HTML, CSS, JS) zu verpacken, und es funktioniert sehr gut.

Bower bezeichnet sich selbst als Paketmanager für das Web. Es wäre großartig, wenn dies wahr wäre - ein Paketmanager, der mein Leben als Front-End-Entwickler verbessert hat, wäre großartig. Das Problem ist, dass Bower keine speziellen Werkzeuge für diesen Zweck anbietet. Es bietet KEINE Tools, von denen ich weiß, dass npm dies nicht tut, und insbesondere keine, die speziell für Front-End-Entwickler nützlich sind. Es ist einfach kein Vorteil für einen Front-End-Entwickler, Bower über npm zu verwenden.

Wir sollten aufhören, Laube zu benutzen und uns gegen npm festigen. Zum Glück passiert genau das :

Mit browserify oder webpack wird es sehr einfach, alle Ihre Module zu großen, minimierten Dateien zu verketten, was sich positiv auf die Leistung auswirkt, insbesondere für mobile Geräte. Nicht so bei Bower, bei dem deutlich mehr Arbeit erforderlich ist, um den gleichen Effekt zu erzielen.

npm bietet Ihnen auch die Möglichkeit, mehrere Versionen von Modulen gleichzeitig zu verwenden. Wenn Sie nicht viel Anwendungsentwicklung durchgeführt haben, könnte dies zunächst eine schlechte Sache für Sie sein, aber wenn Sie ein paar Phasen der Abhängigkeitshölle durchlaufen haben, werden Sie feststellen, dass es ziemlich verdammt ist, mehrere Versionen eines Moduls zu haben tolles Feature. Beachten Sie, dass NPM ein sehr handliches enthält dedupe Werkzeug , das automatisch dafür sorgt , dass Sie nur zwei Versionen eines Moduls verwenden , wenn Sie tatsächlich haben , um - wenn zwei Module beide können die gleiche Version eines Moduls verwenden, werden sie. Aber wenn sie nicht können , haben Sie ein sehr handliches heraus.

(Beachten Sie, dass Webpack und Rollup ab August 2016 allgemein als besser als Browserify angesehen werden.)

Bower verwaltet eine einzelne Version von Modulen und versucht nur, Ihnen bei der Auswahl der richtigen / besten für Sie zu helfen.

Javascript-Abhängigkeitsmanagement: npm vs bower vs volo?

NPM ist besser für Knotenmodule, da es ein Modulsystem gibt und Sie lokal arbeiten. Bower ist gut für den Browser, da es derzeit nur den globalen Bereich gibt und Sie sehr wählerisch bei der Version sein möchten, mit der Sie arbeiten.

Mein Team ist von Bower weggezogen und auf npm umgestiegen, weil:

• Der programmatische Gebrauch war schmerzhaft
• Bowers Benutzeroberfläche änderte sich ständig
• Einige Funktionen, wie die URL-Kurzform, sind vollständig fehlerhaft
• Die Verwendung von Bower und npm im selben Projekt ist schmerzhaft
• Es ist schmerzhaft, das Versionsfeld von bower.json mit Git-Tags synchron zu halten
• Quellcodeverwaltung! = Paketverwaltung
• Die Unterstützung von CommonJS ist nicht einfach

Weitere Informationen finden Sie unter "Warum mein Team npm anstelle von bower verwendet" .

Diese nützliche Erklärung finden Sie unter http://ng-learn.org/2013/11/Bower-vs-npm/

Einerseits wurde npm erstellt, um Module zu installieren, die in einer node.js-Umgebung verwendet werden, oder Entwicklungstools, die mit node.js wie Karma, Lint, Minifiers usw. erstellt wurden. npm kann Module lokal in einem Projekt (standardmäßig in node_modules) oder global installieren, um von mehreren Projekten verwendet zu werden. In großen Projekten können Sie Abhängigkeiten angeben, indem Sie eine Datei mit dem Namen package.json erstellen, die eine Liste von Abhängigkeiten enthält. Diese Liste wird von npm erkannt, wenn Sie npm install ausführen, das sie dann herunterlädt und für Sie installiert.

Auf der anderen Seite wurde Bower erstellt, um Ihre Frontend-Abhängigkeiten zu verwalten. Bibliotheken wie jQuery, AngularJS, Unterstrich usw. Ähnlich wie bei npm gibt es eine Datei, in der Sie eine Liste von Abhängigkeiten mit dem Namen bower.json angeben können. In diesem Fall werden Ihre Frontend-Abhängigkeiten installiert, indem Sie bower install ausführen, das sie standardmäßig in einem Ordner namens bower_components installiert.

Wie Sie sehen, sind sie, obwohl sie eine ähnliche Aufgabe ausführen, auf eine ganz andere Gruppe von Bibliotheken ausgerichtet.

Für viele Leute, die mit node.js arbeiten, besteht ein Hauptvorteil von bower darin, Abhängigkeiten zu verwalten, die überhaupt kein Javascript sind. Wenn sie mit Sprachen arbeiten, die mit Javascript kompiliert werden, kann npm verwendet werden, um einige ihrer Abhängigkeiten zu verwalten. Es werden jedoch nicht alle Abhängigkeiten Node.js-Module sein. Einige von denen, die mit Javascript kompiliert werden, haben möglicherweise eine seltsame quellsprachenspezifische Verfälschung, die das Weitergeben an Javascript zu einer uneleganten Option macht, wenn Benutzer Quellcode erwarten.

Nicht alles in einem npm-Paket muss benutzerorientiertes Javascript sein, aber für npm-Bibliothekspakete sollte zumindest ein Teil davon vorhanden sein.