Jaka jest różnica między Bowerem a npm?

Jaka jest zasadnicza różnica między bower a npm? Chcę czegoś prostego i prostego. Widziałem, jak niektórzy z moich kolegów używają bower i npm zamiennie w swoich projektach.

Author: Haifeng Zhang, 2013-09-05
Source

9 answers

Wszystkie Menedżery pakietów mają wiele wad. Musisz tylko wybrać, z którym możesz żyć.

Historia

Npm rozpoczął zarządzanie węzłem.Moduły js (dlatego Pakiety domyślnie trafiają do node_modules), ale działa to również dla front-endu w połączeniu z Browserify lub WebPack.

Bower jest stworzony wyłącznie dla front-endu i jest zoptymalizowany z myślą o tym.

Wielkość repo

Npm jest znacznie, znacznie większy niż bower, w tym JavaScript ogólnego przeznaczenia (jak {[1] } dla informacji o kraju lub sorts dla funkcji sortowania, które są użyteczne na przedniej lub tylnej stronie).

Bower ma znacznie mniejszą ilość pakietów.

Obsługa stylów itp

Bower zawiera style itp.

Npm koncentruje się na JavaScript. Style są pobierane osobno lub wymagane przez coś w rodzaju npm-sass lub sass-npm.

Obsługa zależności

Największą różnicą jest to, że npm nie zagnieżdżone zależności (ale domyślnie są płaskie), podczas gdy Bower wymaga płaskiego drzewa zależności (obciąża użytkownika rozwiązywaniem zależności) .

Zagnieżdżone drzewo zależności oznacza, że Twoje zależności mogą mieć swoje własne zależności, które mogą mieć swoje własne, i tak dalej. Dzięki temu dwa moduły mogą wymagać różnych wersji tej samej depndency i nadal działać. Uwaga od npm v3 drzewo zależności będzie domyślnie płaskie (oszczędzając miejsce) i zagnieżdżone tylko tam, gdzie jest to potrzebne, np. jeśli dwa zależności potrzebują własnej wersji podkreślenia.

Niektóre projekty używają zarówno Bowera do pakietów front-endu, jak i npm do narzędzi programistycznych, takich jak Yeoman, Grunt, Gulp, JSHint, CoffeeScript itp.

Zasoby

 1842
Author: Sindre Sorhus,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-29 11:57:23

Odpowiedź ta jest uzupełnieniem odpowiedzi Sindre Sorhus. Główną różnicą między npm a Bowerem jest sposób, w jaki traktują rekurencyjne zależności. Zauważ, że mogą być używane razem w jednym projekcie.

Na npm FAQ: (archive.org link z 6 września 2015)

O wiele trudniej jest uniknąć konfliktów zależności bez zagnieżdżania zależności. Jest to fundamentalne dla sposobu działania npm i ma okazały się niezwykle udane podejdźcie.

Na Bower homepage:

Bower jest zoptymalizowany pod kątem front-endu. Bower używa płaskiej zależności drzewo, wymagające tylko jednej wersji dla każdego pakietu, zmniejszające obciążenie strony do minimum.

W skrócie, npm ma na celu stabilność. Bower ma na celu minimalne obciążenie zasobów. Jeśli narysujesz strukturę zależności, zobaczysz to:

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

Jak widać instaluje rekurencyjne zależności. Zależność A posiada trzy zainstalowane instancje!

Bower: 

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

Tutaj widzisz, że wszystkie unikalne zależności są na tym samym poziomie.

Po co więc używać npm?

Być może zależność B wymaga innej wersji zależności A niż zależność C. npm instaluje obie wersje tej zależności, więc i tak będzie działać, ale Bower da ci konflikt , ponieważ nie lubi powielania (ponieważ ładowanie tego samego zasobu na stronie internetowej jest bardzo nieefektywne i kosztowne, również może dać kilka poważnych błędów). Będziesz musiał ręcznie wybrać wersję, którą chcesz zainstalować. Może to spowodować złamanie jednej z zależności, ale i tak będziesz musiał to naprawić.

Tak więc, powszechnym zastosowaniem jest Bower dla pakietów, które chcesz opublikować na swoich stronach internetowych (np. runtime , gdzie unikasz powielania) i używać npm do innych rzeczy, takich jak testowanie, budowanie, optymalizacja, sprawdzanie, itp. (np. czas rozwoju , gdzie powielanie jest mniej niepokojące).

Aktualizacja dla npm 3:

Npm 3 nadal robi rzeczy inaczej niż Bower. Zainstaluje zależności globalnie, ale tylko dla pierwszej wersji, którą napotka. Pozostałe wersje są instalowane w drzewie (moduł nadrzędny, następnie node_modules).

  • [node_modules]
    • dep a v1. 0
    • dep B v1. 0
      • dep a v1. 0 (używa roota wersja)
    • dep C v1. 0
        W przeciwieństwie do wersji root, jest to instalacja zagnieżdżona.]}

Aby uzyskać więcej informacji, proponuję przeczytać dokumenty npm 3

 341
Author: Justus Romijn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-05 13:33:22

TL; DR: największą różnicą w codziennym użytkowaniu nie są zagnieżdżone zależności... to różnica między modułami a globalami.

Myślę, że poprzednie plakaty dobrze opisały niektóre z podstawowych wyróżnień. (użycie npm z zagnieżdżonymi zależnościami jest rzeczywiście bardzo pomocne w zarządzaniu dużymi, złożonymi aplikacjami, choć nie sądzę, aby było to najważniejsze rozróżnienie.)

Dziwi mnie jednak, że nikt nie wyjaśnił jednoznacznie jednego z najbardziej fundamentalnych rozróżnienie między Bowerem a npm. Jeśli przeczytasz powyższe odpowiedzi, zobaczysz słowo "moduły" używane często w kontekście npm. Ale mówi się o tym od niechcenia, jakby to była tylko różnica w składni.

Ale to rozróżnienie modułów vs. globals (lub Moduły vs. 'Skrypty') jest prawdopodobnie najważniejszą różnicą między Bowerem a npm. podejście npm do umieszczania wszystkiego w modułach wymaga zmiany sposobu pisania Javascript dla przeglądarki, prawie na pewno na lepsze.

The Bower Approach: Global Resources, Like <script> Tags

W korzeniu, Bower polega na wczytywaniu zwykłych plików skryptów. Cokolwiek zawierają te pliki skryptów, Bower je załaduje. Co w zasadzie oznacza, że Bower jest tak samo jak włączenie wszystkich skryptów w zwykłej <script> ' s W <head> twojego HTML.

Więc, to samo podstawowe podejście, do którego jesteś przyzwyczajony, ale masz kilka ładnych udogodnień automatyzacji: {]}

  • you used to need to Dołącz zależności JS do repo projektu (podczas tworzenia) lub pobierz je za pośrednictwem CDN. Teraz możesz pominąć tę dodatkową wagę pobierania w repo, a ktoś może zrobić szybki bower install i natychmiast mieć to, czego potrzebuje, lokalnie.
  • jeśli zależność Bowera określi swoje własne zależności w bower.json, zostaną one również pobrane dla Ciebie.

Ale poza tym, Bower nie zmienia sposobu pisania javascript. Nic o tym, co wchodzi do plików załadowanych przez Bowera musi się w ogóle zmienić. W szczególności oznacza to, że zasoby dostarczane w skryptach ładowanych przez Bowera będą (zazwyczaj, ale nie zawsze) nadal zdefiniowane jako zmienne globalne, dostępne z dowolnego miejsca w kontekście wykonywania przeglądarki.

W 2007 roku firma została założona przez firmę JS, która od 2007 roku zajmuje się produkcją i dystrybucją oprogramowania JS.]} Na przykład, jeśli kod jest używany w node land (a więc cały kod ładowany przez npm) jest skonstruowany jako moduły (w szczególności jako implementacja formatu CommonJS module format , lub teraz, jako moduł ES6). Tak więc, jeśli używasz NPM do obsługi zależności po stronie przeglądarki (poprzez Browserify lub coś innego, co robi to samo zadanie), będziesz struktura kodu tak samo jak węzeł robi.

Mądrzejsi ludzie niż ja podjęli pytanie " dlaczego Moduły?', ale oto podsumowanie kapsuły:

  • cokolwiek wewnątrz modułu jest w rzeczywistości przestrzenią nazw, co oznacza, że nie jest to już zmienna globalna i nie możesz przypadkowo odwołać się do niej bez zamiaru za.
  • cokolwiek wewnątrz modułu musi być celowo wstrzyknięte do określonego kontekstu (Zwykle innego modułu), aby z niego skorzystać
  • oznacza to, że możesz mieć wiele wersji tej samej zewnętrznej zależności (powiedzmy lodash) w różnych częściach aplikacji i nie będą one kolidować/konfliktować. (Dzieje się to zaskakująco często, ponieważ twój własny kod chce użyć jednej wersji zależności, ale jedna z zewnętrznych zależności określa inną, która jest sprzeczna. Albo masz dwie zewnętrzne zależności, z których każda chce innej wersji.)
  • ponieważ wszystkie zależności są ręcznie wstrzykiwane do konkretnego modułu, bardzo łatwo jest o nich myśleć. Wiesz na pewno: "jedynym kodem, który muszę wziąć pod uwagę podczas pracy nad tym, jest to, co celowo wybrałem do wstrzyknięcia tutaj" .
  • ponieważ nawet zawartość wtryskiwanych modułów jest zamknięta za zmienną, do której ją przypisujesz, a cały kod wykonuje się wewnątrz ograniczony zasięg, niespodzianki i kolizje stają się bardzo nieprawdopodobne. Jest znacznie, znacznie mniej prawdopodobne, że coś z jednej z Twoich zależności przypadkowo zdefiniuje zmienną globalną bez twojej świadomości, lub że to zrobisz. (To Może się zdarzyć, ale zazwyczaj trzeba iść na swój sposób, aby to zrobić, z czymś takim jak window.variable. Jedynym przypadkiem, który wciąż ma tendencję do występowania, jest przypisanie this.variable, nie zdając sobie sprawy, że this jest rzeczywiście window w bieżącym kontekście.)
  • kiedy chcesz aby przetestować indywidualny moduł, możesz bardzo łatwo wiedzieć: co jeszcze (zależności) ma wpływ na kod, który działa wewnątrz modułu? A ponieważ wyraźnie wstrzykiwasz wszystko, możesz łatwo wyśmiewać te zależności.

Dla mnie użycie modułów do kodu front-endu sprowadza się do: pracy w znacznie węższym kontekście, który jest łatwiejszy do rozumowania i testowania oraz większej pewności co do tego, co się dzieje.

To zajmuje tylko około 30 sekund aby dowiedzieć się, jak używać składni modułu CommonJS/Node. W podanym pliku JS, który będzie modułem, najpierw deklarujesz wszelkie zewnętrzne zależności, których chcesz użyć, jak to:

var React = require('react');

Wewnątrz pliku / modułu, robisz to, co normalnie, i tworzysz jakiś obiekt lub funkcję, które chcesz ujawnić zewnętrznym użytkownikom, nazywając ją być może myModule.

Na końcu pliku eksportujesz wszystko, co chcesz udostępnić światu, jak to:

module.exports = myModule;

Następnie, aby użyć wspólnego obiegu pracy opartego na js w przeglądarce, użyjesz narzędzi takich jak Browserify, aby pobrać wszystkie te pojedyncze pliki modułów, zamknąć ich zawartość w czasie wykonywania i wstrzyknąć je do siebie w razie potrzeby.

A ponieważ moduły ES6 (które prawdopodobnie przeniesiesz do ES5 za pomocą Babel lub podobnego) zyskują szeroką akceptację i działają zarówno w przeglądarce, jak i w Node 4.0, powinniśmy wspomnieć o dobrym przeglądzie {48]} tych również.

Więcej o szablonach do pracy z modułami w tej Talii .

EDIT (Luty 2017): Facebook Yarn jest bardzo ważnym potencjalnym zamiennikiem / suplementem dla npm w dzisiejszych czasach: szybkie, deterministyczne, offline Zarządzanie pakietami, które opiera się na tym, co daje npm. Warto poszukać dowolnego projektu JS, szczególnie, że tak łatwo jest go wymienić / wymienić.

 256
Author: XML,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-07 07:39:28

2017-Aktualizacja października

Bower został w końcu przestarzały . Koniec historii.

Starsza odpowiedź

Od Mattiasa Pettera Johanssona, programisty JavaScript w Spotify :

W prawie wszystkich przypadkach bardziej odpowiednie jest użycie Browserify i npm nad Bowerem. Jest to po prostu lepsze rozwiązanie do pakowania aplikacji front-end niż Bower. W Spotify używamy npm do pakowania całych modułów internetowych (html, css, js) i działa bardzo dobrze.

Bower brands sam jako menedżer pakietów dla sieci. Byłoby wspaniale , gdyby to była prawda-menedżer pakietów, który poprawił moje życie jako programista front-end, byłby niesamowity. Problem polega na tym, że Bower nie oferuje specjalistycznego oprzyrządowania do tego celu. Nie oferuje żadnych narzędzi, o których Wiem, że npm nie ma, a zwłaszcza żadnego, który jest szczególnie przydatny dla programistów front-end. po prostu nie ma korzyści dla programisty front-end, aby używać Bower nad npm.

Powinniśmy przestać używać bower i konsolidacja wokół npm. Na szczęście tak się dzieje :

Liczniki modułów-bower vs. npm

Dzięki browserify lub webpack bardzo łatwo jest połączyć wszystkie moduły w duże, zminifikowane pliki, co jest niesamowite pod względem wydajności, szczególnie w przypadku urządzeń mobilnych. Nie tak z Bowerem, który będzie wymagał znacznie więcej pracy, aby uzyskać ten sam efekt.

Npm oferuje również możliwość korzystania z wielu wersji modułów jednocześnie. Jeśli nie zajmowałeś się zbytnio rozwojem aplikacji, może to początkowo wydawać ci się złą rzeczą, ale po kilku atakach Piekło zależności zdasz sobie sprawę, że posiadanie możliwości posiadania wielu wersji jednego modułu jest całkiem cholernie świetną funkcją. Zauważ, że npm zawiera bardzo poręczne narzędzie dedupe , które automatycznie upewnia się, że używasz tylko dwóch wersji modułu, jeśli faktycznie masz do-Jeśli dwa moduły oba mogą używać ta sama wersja jednego modułu. Ale jeśli oni nie mogą, masz bardzo przydatne wyjście.

(zauważ, żeWebpack i rollup są powszechnie uważane za lepsze niż Browserify od sierpnia 2016.)

 120
Author: Dan Dascalescu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-11-16 21:40:48

Bower utrzymuje jedną wersję modułów, stara się tylko pomóc Ci wybrać właściwą/najlepszą dla Ciebie.

Zarządzanie zależnościami Javascript: npm vs bower vs volo?

Npm jest lepszy dla modułów węzłowych, ponieważ istnieje system modułów i pracujesz lokalnie. Bower jest dobry dla przeglądarki, ponieważ obecnie istnieje tylko zasięg globalny i chcesz być bardzo selektywny co do wersji, z którą pracujesz.

 43
Author: Sagivf,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:55:01

Mój zespół odszedł od Bower i przeniósł się do npm ponieważ:

  • użycie programu było bolesne
  • interfejs Bowera ciągle się zmienia
  • Niektóre funkcje, takie jak skrót adresu url, są całkowicie zepsute
    • Używanie Bowera i npm w tym samym projekcie jest bolesne.]} / Align = "left" / pole wersji json zsynchronizowane z tagami git jest bolesne Kontrola źródła != Zarządzanie pakietami
  • Obsługa CommonJS nie jest prosta

Po więcej szczegółów, zobacz "Dlaczego mój zespół używa npm zamiast bowera" .

 31
Author: Nick Heiner,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-11-21 04:04:51

Znalazłem to przydatne Wyjaśnienie z http://ng-learn.org/2013/11/Bower-vs-npm/

Z jednej strony npm został stworzony do instalacji modułów używanych w węźle.środowisko js, czyli narzędzia programistyczne zbudowane przy użyciu węzła.js takie karmy, lint, minifiers i tak dalej. npm może instalować Moduły lokalnie w projekcie (domyślnie w node_modules ) lub globalnie, aby mogły być używane przez wiele projektów. W dużych projektach sposobem na określenie zależności jest utworzenie pliku o nazwie pakiet.json, który zawiera lista zależności. Lista ta jest rozpoznawana przez npm podczas uruchamiania npm install, który następnie pobiera i instaluje je za Ciebie.

Z drugiej strony bower został stworzony do zarządzania zależnościami interfejsu. Biblioteki takie jak jQuery, AngularJS, underscore, itp. Podobnie jak npm posiada plik, w którym można określić listę zależności o nazwie bower.json. W tym przypadku zależności nakładki są instalowane przez uruchomienie bower install, które domyślnie instaluje je w folderze o nazwie bower_components.

Jak widać, chociaż wykonują podobne zadanie, są kierowane do zupełnie innego zestawu bibliotek.

 14
Author: Henry Neo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-10 03:26:45

Dla wielu osób pracujących z node.js, główną zaletą bowera jest zarządzanie zależnościami, które w ogóle nie są javascript. Jeśli pracują z językami kompilującymi się do javascript, npm może być używany do zarządzania niektórymi ich zależnościami. jednak nie wszystkie ich zależności będą węzłami.Moduły js. Niektóre z tych, które kompilują się do javascript, mogą mieć dziwne zniekształcenia języka źródłowego, które sprawiają, że przekazywanie ich skompilowanych do javascript jest nieelegancką opcją, gdy użytkownicy są oczekuję kodu źródłowego.

Nie wszystko w pakiecie npm musi być nastawione na użytkownika javascript, ale w przypadku pakietów bibliotek npm przynajmniej część z nich powinna być.

 4
Author: jessopher,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-11 21:27:09

Bower i Npm są menedżerami pakietów dla javascript.

Bower

Bower jest tworzony wyłącznie dla rozwoju front-end. Używa płaskiego drzewa zależności, wymagającego tylko jednej wersji dla każdego pakietu, zmniejszając obciążenie strony. Chodzi głównie o minimalne obciążenie zasobów. Ma mniej współpracowników, a więc proces rozwoju jest powolny.

Bower posiada plik konfiguracyjny o nazwie bower.json. W tym Pliku możemy zachować konfigurację dla Bowera jak zależności jakie mamy potrzeba i szczegóły licencji, Opis, Nazwa i tak dalej. Bower nadaje się do pakietów front-end, takich jak jquery, angular, react, ember, knockout, backbone i tak dalej.

Npm

Npm jest najczęściej używany do zarządzania węzłem.Moduły js, ale działa również na front-endzie. Używa zagnieżdżonego drzewa zależności, jak również płaskiego drzewa zależności. Jest popularny i ma wielu współpracowników. Więc jego nowa wersja zawsze wymyśla ekscytujące funkcje.

Npm ma Plik konfiguracyjny nazywa się paczka.json. W tym Pliku możemy zachować konfigurację dla Npm jak zależności, których potrzebujemy i szczegóły licencji, Opis, Nazwa i tak dalej. Npm zapewnia zależności I DevDependencies. Zależności będą pobierać i utrzymywać pliki front-end, takie jak Jquery, Angular i tak dalej. DevDependencies pobierze i utrzyma narzędzia programistyczne takie jak Grunt, Gulp, JSHint i tak dalej.

To oczywiście nie działa tak dobrze na front-endzie, ponieważ potrzebujemy jQuery w naszym projekty. Potrzebujemy tylko jednej kopii jQuery, ale gdy inny pakiet wymaga jQuery, to pobierze ponownie jeszcze jedną kopię jQuery. Jest to jedna z głównych wad Npm.

kluczowa Uwaga: powodem, dla którego wiele projektów używa obu, jest to, że używają Bowera do pakietów front-end i Npm do narzędzi programistycznych. Mnożenie menedżera pakietów w projekcie utrudnia przepływ pracy. Npm 3 w połączeniu z browserify lub webpack jest sposobem, aby przejść teraz.

 1
Author: Abdul Alim Shakir,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-01-07 09:26:35