Frage Was ist der Unterschied zwischen Bower und Npm?


Worin besteht der grundlegende Unterschied? bower und npm? Will einfach etwas Einfaches und Einfaches. Ich habe einige meiner Kollegen gesehen bower und npm austauschbar in ihren Projekten.


1611
2017-09-05 16:53


Ursprung


Antworten:


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 (deshalb gehen Pakete in node_modules Standard), aber es funktioniert auch für das Front-End, wenn es mit kombiniert wird Browserifizieren oder WebPack.

Laube ist ausschließlich für das Front-End gedacht und darauf optimiert.

Größe des Repo

Npm ist viel, viel größer als Laube, einschließlich Allzweck-JavaScript (wie country-data für Länderinformationen oder sorts zum Sortieren von Funktionen, die am Frontend oder am Backend verwendbar sind).

Bower hat eine viel kleinere Menge an Paketen.

Umgang mit Stilen etc

Bower enthält Stile usw.

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

Abhängigkeitsverarbeitung

Der größte Unterschied besteht darin, dass npm geschachtelte Abhängigkeiten verwendet (aber standardmäßig flach ist), während Bower eine flache Abhängigkeitsstruktur benötigt (legt dem Benutzer die Last der Abhängigkeitslösung auf).

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. Dies ermöglicht, dass zwei Module verschiedene Versionen derselben Dependenz benötigen und trotzdem funktionieren. Hinweis: Seit npm v3 wird die Abhängigkeitsbaumstruktur standardmäßig flach (Platz sparend) und nur dort verschachtelt, wo sie benötigt wird, z. B. wenn zwei Abhängigkeiten ihre eigene Version von Underscore benötigen.

Einige Projekte verwenden Bower für Front-End-Pakete und npm für Entwickler-Tools wie Yeoman, Grunt, Gulp, JSHint, CoffeeScript usw.


Ressourcen


1828
2017-09-06 08:09



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

Auf der Npm FAQ: (Archiv.org Link vom 6. September 2015)

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

Auf Laube Startseite:

Bower ist für das Front-End optimiert. Bower verwendet eine flache Abhängigkeit   Baum, der für jedes Paket nur eine Version benötigt, wodurch die Seitenbelastung verringert wird   auf ein Minimum.

Kurz gesagt, npm zielt auf Stabilität. Bower zielt auf minimale Ressourcenbelastung ab. 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 können, 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 alle eindeutigen Abhängigkeiten auf derselben Ebene sind.

Warum also mit npm arbeiten?

Vielleicht benötigt Abhängigkeit B eine andere Version von Abhängigkeit A als Abhängigkeit C. npm installiert beide Versionen dieser Abhängigkeit, so dass es trotzdem funktioniert, aber Bower wird Ihnen einen geben Konflikt weil es die Duplizierung nicht mag (weil das Laden derselben Ressource auf einer Webseite sehr ineffizient und teuer ist, kann es auch einige schwerwiegende Fehler verursachen). Sie müssen manuell auswählen, welche Version Sie installieren möchten. Dies kann dazu führen, dass eine der Abhängigkeiten bricht, aber das müssen Sie trotzdem beheben.

Der übliche Verwendungszweck ist Bower für die Pakete, die Sie auf Ihren Webseiten veröffentlichen möchten (z. Laufzeit, wo Sie Doppelarbeit vermeiden), und verwenden Sie npm für andere Dinge, wie Testen, Erstellen, Optimieren, Prüfen usw. (z.B. Entwicklungszeit, wenn die Duplizierung von geringerer Bedeutung ist).

Update für npm 3:

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

  • [Knotenmodule]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (benutzt Root-Version)
    • dep C v1.0
      • dep A v2.0 (diese Version unterscheidet sich von der Root-Version, daher wird es eine geschachtelte Installation sein)

Für weitere Informationen empfehle ich das Lesen der Dokumente von npm 3


338
2017-11-24 13:10



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

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

Ich bin jedoch überrascht, dass niemand eine der grundlegendsten Unterscheidungen zwischen Bower und npm explizit erklärt hat. Wenn Sie die obigen Antworten lesen, sehen Sie oft das Wort "Module" im Kontext von npm. Aber es wird beiläufig erwähnt, als wäre es vielleicht nur ein Syntaxunterschied.

Aber diese Unterscheidung von Module gegen Globals (oder Module vs. "Skripte") ist möglicherweise der wichtigste Unterschied zwischen Bower und npm. Der npm-Ansatz, alles in Module zu schreiben, erfordert, dass Sie die Art und Weise ändern, wie Sie Javascript für den Browser schreiben, fast sicher zum Besseren.

The Bower Approach: Globale Ressourcen, Like <script> Stichworte

Bei root lädt Bower einfach alte Skriptdateien. Was auch immer diese Skriptdateien enthalten, Lower lädt sie. Was im Grunde bedeutet, dass Bower ist wie alle Ihre Skripte in schlicht-alt <script>ist in der <head> von deinem HTML.

So, wie Sie es gewohnt sind, aber Sie erhalten einige nette Automatisierungsfunktionen:

  • Früher mussten Sie JS-Abhängigkeiten in Ihr Projektrepo aufnehmen (während der Entwicklung) oder über CDN beziehen. Jetzt können Sie das zusätzliche Download-Gewicht im Repo überspringen, und jemand kann schnell handeln bower installund sofort haben, was sie brauchen, lokal.
  • Wenn eine Bower-Abhängigkeit dann ihre eigenen Abhängigkeiten in ihren angibt bower.jsonDiese werden auch für dich heruntergeladen.

Aber darüber hinaus Bower ändert nicht, wie wir Javascript schreiben. Nichts darüber, was in den von Bower geladenen Dateien steckt, muss sich überhaupt ändern. Dies bedeutet insbesondere, dass die Ressourcen, die in von Bower geladenen Skripts zur Verfügung stehen, (normalerweise, aber nicht immer) immer noch als definiert gelten globale Variablen, verfügbar von überall im Browser Ausführungskontext.

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

Der gesamte Code in Node Land (und somit der gesamte über npm geladene Code) ist als Module strukturiert (speziell als Implementierung der CommonJS-Modulformatoder jetzt als ES6-Modul). Wenn Sie also NPM verwenden, um browserseitige Abhängigkeiten zu verarbeiten (über Browserify oder etwas anderes, das die gleiche Aufgabe erfüllt), strukturieren Sie Ihren Code genauso wie Node.

Intelligentere Leute als ich habe die Frage "Warum Module?" Angegangen, aber hier ist eine Zusammenfassung der Kapsel:

  • Alles in einem Modul ist effektiv NamensraumDas bedeutet, dass es keine globale Variable mehr ist und Sie nicht versehentlich darauf verweisen können, ohne es zu wollen.
  • Alles in einem Modul muss absichtlich in einen bestimmten Kontext (normalerweise ein anderes Modul) eingefügt werden, um es zu nutzen
  • Dies bedeutet, dass Sie mehrere Versionen der gleichen externen Abhängigkeit (lodash, sagen wir mal) in verschiedenen Teilen Ihrer Anwendung haben können, und sie werden nicht kollidieren / Konflikt. (Dies geschieht überraschend oft, weil Ihr eigener Code eine Version einer Abhängigkeit verwenden möchte, eine Ihrer externen Abhängigkeiten jedoch eine andere, die Konflikte verursacht. Oder Sie haben zwei externe Abhängigkeiten, die jeweils eine andere Version haben wollen.)
  • Da alle Abhängigkeiten manuell in ein bestimmtes Modul eingefügt werden, ist es sehr einfach, über sie nachzudenken. Du weißt es genau: "Der einzige Code, den ich bei der Arbeit berücksichtigen muss, ist, was ich hier absichtlich gewählt habe".
  • Denn auch der Inhalt von injizierten Modulen ist gekapselt hinter der Variablen, der Sie sie zuweisen, und der gesamte Code in einem begrenzten Umfang ausgeführt wird, werden Überraschungen und Kollisionen sehr unwahrscheinlich. Es ist viel, 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 Sie müssen in der Regel aus dem Weg zu tun, mit etwas wie window.variable. Der einzige Unfall, der immer noch auftritt, ist das Zuweisen this.variabledas nicht zu merken this ist eigentlich window im aktuellen Kontext.)
  • Wenn Sie ein einzelnes Modul testen möchten, können Sie sehr leicht wissen: Was genau (Abhängigkeiten) beeinflusst den Code, der im Modul ausgeführt wird? Und weil Sie explizit alles injezieren, können Sie diese Abhängigkeiten leicht verspotten.

Für mich bedeutet die Verwendung von Modulen für Front-End-Code: Arbeiten in einem viel engeren Kontext, der einfacher zu verstehen und zu testen ist, und mit größerer Gewissheit darüber, was vor sich geht.


Es dauert nur etwa 30 Sekunden, um zu lernen, wie man die Syntax des CommonJS / Node-Moduls verwendet. Innerhalb einer gegebenen JS-Datei, die ein Modul sein wird, deklarieren Sie zuerst alle externen Abhängigkeiten, die Sie verwenden möchten, wie folgt:

var React = require('react');

Innerhalb der Datei / des Moduls machen Sie das, was Sie normalerweise tun würden, und erstellen ein Objekt oder eine Funktion, die Sie externen Benutzern zugänglich machen möchten, indem Sie es vielleicht aufrufen myModule.

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

module.exports = myModule;

Um dann einen CommonJS-basierten Workflow im Browser zu verwenden, verwenden Sie Tools wie Browserify, um alle diese einzelnen Moduldateien zu erfassen, deren Inhalt zur Laufzeit zu kapseln und sie bei Bedarf miteinander zu verknüpfen.

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

Mehr über Muster zum Arbeiten mit Modulen in dieses Deck.


EDIT (Feb 2017): Facebook's Garn ist ein sehr wichtiger potentieller Ersatz / Ergänzung für npm in diesen Tagen: schnelles, deterministisches Offline-Paket-Management, das darauf baut, was npm Ihnen gibt. Es lohnt sich, ein JS-Projekt anzuschauen, zumal es so einfach ist, es ein- und auszuwechseln.


256
2017-07-26 03:12



2017-Okt Aktualisierung

Bower ist endlich da 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 over 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 packen, und es funktioniert sehr gut.

Bower bezeichnet sich selbst als Paketmanager für das Web. Es wäre toll, wenn das stimmt - ein Paketmanager, der mein Leben als Front-End-Entwickler besser gemacht hat, wäre großartig. Das Problem ist, dass Bower keine speziellen Werkzeuge für diesen Zweck anbietet. Es bietet KEINE Werkzeuge, von denen ich weiß, dass npm nicht, und vor allem keine, die speziell für Front-End-Entwickler nützlich ist. Es gibt einfach keinen Vorteil für einen Front-End-Entwickler Bower über Npm zu verwenden.

Wir sollten aufhören, Laube zu benutzen und um npm zu konsolidieren. Zum Glück ist das was es passiert:

Module counts - bower vs. npm

Mit browserify oder webpack wird es sehr einfach, alle Ihre Module zu großen, minimierten Dateien zu verketten, was besonders für mobile Geräte großartig ist. Nicht so bei Bower, was deutlich mehr Arbeit erfordert, um den gleichen Effekt zu erzielen.

npm bietet Ihnen auch die Möglichkeit, mehrere Versionen von Modulen gleichzeitig zu verwenden. Wenn Sie nicht viel Entwicklung von Anwendungen gemacht haben, wird Ihnen dies zunächst als eine schlechte Sache auffallen, aber wenn Sie erst einmal ein paar Anfälle erlebt haben Abhängigkeits-Hölle Sie werden feststellen, dass die Fähigkeit, mehrere Versionen eines Moduls zu haben, ein verdammt gutes Feature ist. Beachten Sie, dass npm ein sehr handliches enthält Deduplizierungswerkzeug das stellt automatisch sicher, dass Sie nur zwei Versionen eines Moduls verwenden, wenn Sie tatsächlich haben zu - wenn zwei Module beide kann Verwenden Sie die gleiche Version eines Moduls, sie werden. Aber wenn sie kippenDu hast ein sehr handliches Out.

(Beachten Sie, dass Webpaket und aufrollen werden seit August 2016 als besser angesehen als Browserify.)


117
2017-07-04 10:48



Bower unterhält eine einzelne Version der Module, es versucht nur Ihnen zu helfen, die richtige / beste für Sie auszuwählen.

Javascript Abhängigkeitsmanagement: Npm gegen 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 selektiv in Bezug auf die Version arbeiten möchten, mit der Sie arbeiten.


43
2017-07-19 20:59



Mein Team zog von Bower weg und wanderte nach npm aus, weil:

  • Der programmatische Gebrauch war schmerzhaft
  • Bower's Interface änderte sich ständig
  • Einige Funktionen, wie die URL-Kurzschrift, sind vollständig unterbrochen
  • Die Verwendung von Bower und npm im selben Projekt ist schmerzhaft
  • Es ist schmerzhaft, das Feld "bower.json version" synchron mit Git-Tags zu halten
  • Versionskontrolle! = Paketverwaltung
  • Die Unterstützung von CommonJS ist nicht einfach

Für weitere Details, siehe "Warum mein Team npm anstelle von bower verwendet".


31
2018-02-16 21:04



Fanden Sie diese nützliche Erklärung von 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 besteht die Möglichkeit, Abhängigkeiten anzugeben, darin, eine Datei namens package.json zu erstellen, die eine Liste von Abhängigkeiten enthält. Diese Liste wird von npm erkannt, wenn Sie npm install ausführen, das sie dann für Sie herunterlädt und installiert.

Auf der anderen Seite wurde Bower erstellt, um Ihre Frontend-Abhängigkeiten zu verwalten. Bibliotheken wie jQuery, AngularJS, Unterstreichung usw. Ähnlich wie npm gibt es eine Datei, in der Sie eine Liste von Abhängigkeiten namens bower.json angeben können. In diesem Fall werden Ihre Frontend-Abhängigkeiten durch die Installation von bower install installiert, die sie standardmäßig in einem Ordner namens bower_components installiert.

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


14
2017-10-03 00:08



Für viele Leute, die mit node.js arbeiten, besteht ein großer Vorteil von bower darin, Abhängigkeiten zu verwalten, die überhaupt kein JavaScript sind. Wenn sie mit Sprachen arbeiten, die zu Javascript kompilieren, kann npm verwendet werden, um einige ihrer Abhängigkeiten zu verwalten. Nicht alle ihre Abhängigkeiten werden jedoch node.js-Module sein. Einige von denen, die zu Javascript kompilieren, können merkwürdige quellensprache spezifische Mangling haben, die das Umgehen sie herum kompiliert zu Javascript eine unelegante Wahl macht, wenn Benutzer Quellcode erwarten.

Nicht alles in einem npm-Paket muss Javascript sein, das auf den Benutzer ausgerichtet ist, aber für npm-Bibliothekspakete sollte zumindest ein Teil davon sein.


4
2017-10-11 20:42



Bower und Npm sind Paketmanager für Javascript.

Laube

Bower wird ausschließlich für die Frontend-Entwicklung entwickelt. Es verwendet eine flache Abhängigkeitsstruktur, die nur eine Version für jedes Paket erfordert, wodurch die Seitenbelastung verringert wird. Es zielt hauptsächlich auf minimale Ressourcenbelastung ab. Es hat weniger Beiträge und daher ist der Entwicklungsprozess langsam.

Bower hat eine Konfigurationsdatei namens bower.json. In dieser Datei können wir die Konfiguration für Bower wie die Abhängigkeiten, die wir benötigen und Lizenzdetails, Beschreibung, Name usw. pflegen. Bower eignet sich für Front-End-Pakete wie Jquery, eckig, reagieren, Glut, Knockout, Backbone und so weiter.

Npm

Npm wird am häufigsten zum Verwalten von Node.js-Modulen verwendet, funktioniert aber auch für das Front-End. Es verwendet eine geschachtelte Abhängigkeitsstruktur sowie eine flache Abhängigkeitsstruktur. Es ist beliebt und hat viele Mitwirkende. Die neue Version bietet also immer wieder aufregende Funktionen.

Npm hat eine Konfigurationsdatei namens package.json. In dieser Datei können wir die Konfiguration für Npm wie die Abhängigkeiten, die wir benötigen und Lizenzdetails, Beschreibung, Name und so weiter pflegen. Npm bietet Abhängigkeiten und DevDependencies. Abhängigkeiten laden und pflegen die Front-End-Dateien wie Jquery, Angular und so weiter. DevDependencies wird Entwicklungswerkzeuge wie Grunt, Gulp, JSHint usw. herunterladen und pflegen.

Das funktioniert natürlich nicht so gut am Frontend, denn wir brauchen jQuery in unseren Projekten. Wir brauchen nur eine Kopie von jQuery, aber wenn ein anderes Paket jQuery benötigt, wird es erneut eine Kopie von jQuery herunterladen. Dies ist einer der Hauptnachteile von Npm.

Key Hinweis: Der Grund, warum viele Projekte beide verwenden, ist, dass sie Bower für Front-End-Pakete und Npm für Entwickler-Tools verwenden. Durch Multiplizieren des Paketmanagers in Ihrem Projekt wird Ihr Arbeitsablauf erschwert. Npm 3 gekoppelt mit browserifizieren oder Webpaket ist der Weg jetzt zu gehen.


1
2018-01-07 09:26