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

Jaka jest podstawowa różnica między boweri npm? Po prostu chcę coś prostego i prostego. Widziałem, jak niektórzy z moich kolegów używają boweri npmzamiennie w swoich projektach.

Wszyscy menedżerowie pakietów mają wiele wad. Musisz tylko wybrać, z kim możesz żyć.

Historia

npm rozpoczął zarządzanie modułów node.js (dlatego pakiety wchodzić node_modulesdomyślnie), ale działa na front-end też w połączeniu z Browserify lub WebPack .

Bower został stworzony wyłącznie z myślą o interfejsie użytkownika i został zoptymalizowany pod tym kątem.

Rozmiar repo

npm jest znacznie, dużo większy niż altana, włączając w to JavaScript ogólnego przeznaczenia (np. country-datado informacji o kraju lub sortsdo funkcji sortowania, które można wykorzystać na interfejsie lub na zapleczu).

Bower ma znacznie mniejszą liczbę paczek.

Obsługa stylów itp

Bower zawiera style itp.

npm koncentruje się na JavaScript. Style są pobierane osobno lub wymagane przez coś takiego jak npm-sasslub sass-npm.

Obsługa zależności

Największą różnicą jest to, że npm robi zagnieżdżone zależności (ale domyślnie jest płaska), podczas gdy Bower wymaga płaskiego drzewa zależności (nakłada na użytkownika ciężar rozwiązywania zależności) .

Zagnieżdżone drzewo zależności oznacza, że ​​twoje zależności mogą mieć własne zależności, które mogą mieć swoje własne i tak dalej. Dzięki temu dwa moduły wymagają różnych wersji tej samej zależności i nadal działają. Zauważ, że od npm v3, drzewo zależności domyślnie będzie płaskie (oszczędność miejsca) i zagnieżdżone tylko tam, gdzie będzie to potrzebne, np. Jeśli dwie zależności potrzebują własnej wersji podkreślenia.

Niektóre projekty używają obu, ponieważ używają Bowera do pakietów frontonu i npm do narzędzi programistycznych takich jak Yeoman, Grunt, Gulp, JSHint, CoffeeScript itp.

Zasoby

• Zagnieżdżone zależności - wgląd w to, dlaczego moduły_węzłów działają tak, jak działają

Ta odpowiedź jest dodatkiem do odpowiedzi Sindre Sorhus. Główną różnicą między npm i Bower jest sposób, w jaki traktują zależności rekurencyjne. Pamiętaj, że można ich używać razem w jednym projekcie.

Na npm FAQ : (archive.org powiązanie z 6 wrz 2015)

O wiele trudniej jest unikać konfliktów zależności bez zagnieżdżania zależności. Ma to zasadnicze znaczenie dla sposobu działania npm i okazało się, że jest to niezwykle skuteczne podejście.

Na stronie głównej Bower :

Altana jest zoptymalizowana pod kątem interfejsu. Bower używa płaskiego drzewa zależności, wymagając tylko jednej wersji dla każdego pakietu, co zmniejsza obciążenie strony do minimum.

Krótko mówiąc, npm dąży do stabilności. Bower dąży do minimalnego obciążenia 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 rekurencyjnie niektóre zależności. Zależność A ma trzy zainstalowane instancje!

Altana:

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 męczyć się z użyciem 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 duplikacji (ponieważ ładowanie tego samego zasobu na stronie jest bardzo nieefektywne i kosztowne, może również powodować poważne błędy). Będziesz musiał ręcznie wybrać wersję, którą chcesz zainstalować. Może to spowodować uszkodzenie jednej z zależności, ale i tak trzeba to naprawić.

Tak więc, powszechnym zastosowaniem jest Bower dla pakietów, które chcesz publikować na swoich stronach internetowych (np. Środowisko wykonawcze , w którym unikasz powielania) i używaj npm do innych rzeczy, takich jak testowanie, budowanie, optymalizacja, sprawdzanie itp. (Np. Czas programowania , gdzie powielanie jest mniej istotne).

Aktualizacja dla npm 3:

npm 3 nadal robi rzeczy inaczej niż Bower. Zainstaluje zależności globalnie, ale tylko dla pierwszej napotkanej wersji. Pozostałe wersje są zainstalowane w drzewie (moduł nadrzędny, a następnie moduły_węzła).

• [node_modules]
  • dep A v1.0
  • dep B v1.0
    • dep A v1.0 (używa wersji root)
  • dep C v1.0
    • dep A v2.0 (ta wersja różni się od wersji root, więc będzie to instalacja zagnieżdżona)

Aby uzyskać więcej informacji, sugeruję przeczytanie dokumentacji npm 3

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

Myślę, że poprzednie plakaty dobrze opisywały niektóre podstawowe wyróżnienia. (użycie zagnieżdżonych zależności przez npm jest naprawdę bardzo pomocne w zarządzaniu dużymi, złożonymi aplikacjami, choć nie sądzę, że jest to najważniejsze rozróżnienie).

Dziwi mnie jednak fakt, że nikt nie wyjaśnił jednoznacznie jednej z najbardziej podstawowych różnic między Bower a npm. Jeśli przeczytasz powyższe odpowiedzi, zobaczysz słowo „moduły” używane często w kontekście npm. Ale wspomina się o tym od niechcenia, jakby to była tylko różnica w składni.

Ale to rozróżnienie modułów na globale (lub modułów na „skrypty”) jest prawdopodobnie najważniejszą różnicą między Bower a npm. Podejście NPM polegające na umieszczaniu wszystkiego w modułach wymaga zmiany sposobu pisania Javascript dla przeglądarki, prawie na pewno na lepsze.

Podejście Bower: globalne zasoby, takie jak <script>tagi

W katalogu głównym Bower polega na ładowaniu zwykłych plików skryptów. Cokolwiek zawierają te pliki skryptów, Bower je załaduje. Co w zasadzie oznacza, że ​​Bower jest po prostu włączeniem wszystkich twoich skryptów do zwykłych starych <script>w <head>twoim HTML.

Więc to samo podstawowe podejście, do którego jesteś przyzwyczajony, ale masz kilka fajnych udogodnień automatyzacji:

• W repozytorium projektu trzeba było uwzględniać zależności JS (podczas opracowywania) lub uzyskiwać je za pośrednictwem CDN. Teraz możesz pominąć tę dodatkową wagę pobierania w repozytorium, a ktoś może zrobić szybko bower installi natychmiast mieć to, czego potrzebuje, lokalnie.
• Jeśli zależność Bowera określa w niej własne zależności bower.json, zostaną one również pobrane dla Ciebie.

Ale poza tym Bower nie zmienia sposobu, w jaki piszemy javascript . Nic, co znajduje się w plikach ładowanych przez Bowera, nie musi się w ogóle zmieniać. W szczególności oznacza to, że zasoby dostarczone w skryptach ładowanych przez Bowera (zwykle, ale nie zawsze) będą nadal definiowane jako zmienne globalne , dostępne z dowolnego miejsca w kontekście wykonywania przeglądarki.

Podejście npm: wspólne moduły JS, jawne wstrzykiwanie zależności

Cały kod w obszarze Node (a więc cały kod ładowany przez npm) ma strukturę modułów (w szczególności jako implementację formatu modułu CommonJS 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 wykonuje tę samą pracę), ustrukturyzujesz swój kod w ten sam sposób, co robi Node.

Ludzie mądrzejsi ode mnie poradzili sobie z pytaniem „Dlaczego moduły?”, Ale oto podsumowanie kapsułek:

• Wszystko wewnątrz modułu ma efektywną przestrzeń nazw , co oznacza, że ​​nie jest już zmienną globalną i nie można przypadkowo odwoływać się do niej bez zamiaru.
• Wszystko wewnątrz modułu musi być celowo wstrzykiwane w określony kontekst (zwykle inny moduł), aby z niego skorzystać
• Oznacza to, że możesz mieć wiele wersji tej samej zależności zewnętrznej (powiedzmy lodash) w różnych częściach aplikacji i nie będą one kolidować / konfliktować. (Zdarza 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 powoduje konflikt. Lub masz dwie zależności zewnętrzne, z których każda chce innej wersji).
• Ponieważ wszystkie zależności są ręcznie wstrzykiwane do określonego modułu, bardzo łatwo jest je zrozumieć. Wiesz na pewno : „Jedynym kodem, który muszę wziąć pod uwagę, pracując nad tym, jest to, co celowo wybrałem tutaj . ”
• Ponieważ nawet zawartość wstrzykiwanych modułów jest zamknięta za zmienną, do której ją przypisujesz, a cały kod jest wykonywany w ograniczonym zakresie, niespodzianki i kolizje stają się bardzo nieprawdopodobne. Jest o wiele, znacznie mniej prawdopodobne, że coś z jednej z twoich zależności przypadkowo przedefiniuje zmienną globalną, nie zdając sobie z tego sprawy, lub że to zrobisz. (Może się to zdarzyć, ale zwykle musisz zrobić wszystko, aby to zrobić, z czymś takim window.variable. Jedynym wypadkiem, który wciąż ma miejsce, jest przypisanie this.variable, nie zdając sobie sprawy, że thistak naprawdę jest windoww obecnym kontekście.)
• Kiedy chcesz przetestować pojedynczy moduł, możesz bardzo łatwo wiedzieć: co dokładnie (zależności) wpływa na kod działający w module? A ponieważ jawnie wstrzykujesz wszystko, możesz łatwo wyśmiewać te zależności.

Dla mnie użycie modułów w kodzie front-end sprowadza się do: pracy w znacznie węższym kontekście, łatwiejszym do przemyślenia i przetestowania, oraz większej pewności co do tego, co się dzieje.

Nauka używania składni modułu CommonJS / Node zajmuje tylko około 30 sekund. Wewnątrz pliku JS, który będzie modułem, najpierw zadeklarujesz zależności zewnętrzne, których chcesz użyć, na przykład:

var React = require('react');

Wewnątrz pliku / modułu robisz wszystko, co zwykle, i tworzysz jakiś obiekt lub funkcję, którą chcesz udostępnić użytkownikom zewnętrznym, być może nazywając to myModule.

Na końcu pliku eksportujesz wszystko, co chcesz udostępnić światu, w następujący sposób:

module.exports = myModule;

Następnie, aby użyć przepływu pracy opartego na CommonJS w przeglądarce, użyjesz narzędzi takich jak Browserify, aby pobrać wszystkie te pojedyncze pliki modułów, obudować ich zawartość w czasie wykonywania i wstrzyknąć je sobie w razie potrzeby.

ORAZ, ponieważ moduły ES6 (które najprawdopodobniej przeniesiesz do ES5 z Babel lub podobnym) zyskują szeroką akceptację i działają zarówno w przeglądarce, jak i w Node 4.0, powinniśmy również wspomnieć o ich dobrym przeglądzie .

Więcej informacji o wzorach do pracy z modułami w tym pokładzie .

EDYCJA (luty 2017): Przędza Facebooka jest obecnie bardzo ważnym potencjalnym zamiennikiem / suplementem dla npm: szybkie, deterministyczne, zarządzanie pakietami offline, które opiera się na tym, co daje ci npm. Warto poszukać każdego projektu JS, zwłaszcza, że ​​tak łatwo jest go zamienić na.

EDYCJA (maj 2019) „Bower jest już przestarzały . Koniec historii”. (h / t: @DanDascalescu, poniżej, dla zwięzłego podsumowania.)

I podczas gdy Przędza jest nadal aktywna , znaczna rozpęd powróciła do npm, kiedy przyjęła niektóre kluczowe cechy Przędzy.

Aktualizacja 2017-paź

Bower został w końcu przestarzały . Koniec opowieści.

Starsza odpowiedź

Od Mattias Petter Johansson, programista JavaScript w Spotify :

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

Bower określa się mianem menedżera pakietów w Internecie. Byłoby wspaniale, gdyby to była prawda - menedżer pakietów, który poprawiłby moje życie jako programista front-end, byłby niesamowity. Problem polega na tym, że Bower nie oferuje do tego celu specjalistycznych narzędzi. Nie oferuje żadnych narzędzi, o których wiem, że nie ma npm, a zwłaszcza żadnego, który jest szczególnie przydatny dla programistów frontonu. Po prostu nie ma korzyści dla frontendowego programisty, który używałby Bowera nad npm.

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

Dzięki Browserify lub webpack bardzo łatwo jest połączyć wszystkie moduły w duże, zminimalizowane pliki, co jest niesamowite pod względem wydajności, szczególnie w przypadku urządzeń mobilnych. Nie w przypadku Bowera, 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 opracowałeś dużo aplikacji, może się to początkowo wydawać złe, ale po przejściu kilku ataków piekła Zależności zdasz sobie sprawę, że możliwość posiadania wielu wersji jednego modułu jest dość cholerna świetna funkcja. Zauważ, że npm zawiera bardzo przydatne narzędzie dedupe, które automatycznie upewnia się, że używasz tylko dwóch wersji modułu, jeśli naprawdę musisz - jeśli dwa moduły mogą korzystać z tej samej wersji jednego modułu, to zrobią to. Ale jeśli nie mogą , masz bardzo przydatne.

(Uwaga: pakiet Webpack i pakiet zbiorczy są powszechnie uważane za lepsze niż Browserify od sierpnia 2016 r.)

Bower utrzymuje jedną wersję modułów, stara się jedynie pomóc wybrać odpowiedni / najlepszy dla Ciebie.

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

NPM jest lepszy dla modułów węzłów, 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 wybiórczy w kwestii wersji, z którą pracujesz.

Mój zespół odszedł od Bowera i przeprowadził się do npm, ponieważ:

• Programowe użycie było bolesne
• Interfejs Bowera ciągle się zmieniał
• Niektóre funkcje, takie jak skróty adresów URL, są całkowicie zepsute
• Używanie Bower i npm w tym samym projekcie jest bolesne
• Utrzymywanie synchronizacji pola wersji bower.json z tagami git jest bolesne
• Kontrola źródła! = Zarządzanie pakietami
• Obsługa CommonJS nie jest prosta

Aby uzyskać więcej informacji, zobacz „Dlaczego mój zespół używa npm zamiast altany” .

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

Z jednej strony stworzono npm do instalacji modułów używanych w środowisku node.js lub narzędzi programistycznych zbudowanych przy użyciu node.js takich jak Karma, włókna, minizatory i tak dalej. npm może instalować moduły lokalnie w projekcie (domyślnie w module_węzła) lub globalnie do użytku w wielu projektach. W dużych projektach sposobem określania zależności jest utworzenie pliku o nazwie package.json, który zawiera listę zależności. Ta lista jest rozpoznawana przez npm po uruchomieniu instalacji npm, która następnie pobiera i instaluje je dla ciebie.

Z drugiej strony altana została stworzona do zarządzania twoimi zależnościami frontendowymi. Biblioteki takie jak jQuery, AngularJS, podkreślenie itp. Podobnie jak npm, ma plik, w którym można określić listę zależności o nazwie bower.json. W tym przypadku zależności interfejsu użytkownika są instalowane przez uruchomienie instalacji bower, która domyślnie instaluje je w folderze o nazwie bower_components.

Jak widać, mimo że wykonują podobne zadanie, są skierowane do zupełnie innego zestawu bibliotek.

Dla wielu osób pracujących z node.js główną zaletą bower jest zarządzanie zależnościami, które wcale nie są javascript. Jeśli pracują z językami kompilującymi się w javascript, npm może być użyty do zarządzania niektórymi z ich zależności. jednak nie wszystkie ich zależności będą modułami node.js. Niektóre z tych, które kompilują się do javascript, mogą mieć dziwne zniekształcenie specyficzne dla języka źródłowego, co sprawia, że ​​przekazywanie ich w kompilacji do javascript jest nieelegantną opcją, gdy użytkownicy oczekują kodu źródłowego.

Nie wszystko w pakiecie npm musi być skryptem JavaScript skierowanym do użytkownika, ale w przypadku pakietów biblioteki npm przynajmniej niektóre z nich powinny być.