Zarządzanie zależnościami JavaScript: npm vs. bower vs. volo [zamknięte]


160

Jak można porównać npm, boweri volo?

Wszystkie trzy mogą służyć do instalowania zależności JavaScript dla projektu interfejsu użytkownika. Rozumiem, że npmjest bardziej specyficzny dla węzła.

Kiedy więc czego użyć?

npmstoi odległe, ale boweri volowydają się być rozwiązywaniu dokładnie ten sam problem, choć nie jestem w stanie narysować linię pomiędzy npmi bower-volo.



1
Jeśli czytasz to pytanie i chcesz odpowiedzi z 2015 roku, zobacz moją zaktualizowaną odpowiedź.
gustavohenke

Odpowiedzi:


104

Opis najlepiej opisujący różnicę między npm a bower to: npm zarządza modułami JavaScript zwanymi pakietami, a Bower zarządza komponentami front-end (np. Css, html i JavaScript) zwanymi komponentami. npm służy również do montażu altany. Tutaj jest obszerny artykuł na temat npm i altany (nie obejmuje volo), zawiera wiele szczegółów.


88
To nie jest dobry opis. Npm z pewnością można wykorzystać do zainstalowania komponentów frontonu.
BT

Chociaż zauważyłem, że niektóre biblioteki "frontendowe" na npm zostały porzucone na rzecz swoich odpowiedników w bowerach. Weźmy na przykład Ember , który nie został opublikowany od roku.
briangonzalez

4
@Nate Nazwa jest po prostu tam, gdzie się zaczęła. NPM jest teraz systemem zarządzania pakietami bardzo ogólnego przeznaczenia. Regularnie używam npm do instalowania modułów front-end. Nie ma różnicy w używaniu NPM dla modułów commonjs, vs amd, vs cokolwiek innego. Możesz również użyć npm dla modułów innych niż javascript. Dlatego po prostu nie ma różnicy między npm a bower. Niezależnie od tego, czy nazywasz je pakietami, czy komponentami, są one takie same, ponieważ są zbiorami dowolnych plików.
BT,

2
Jest to bardzo myląca odpowiedź, biorąc pod uwagę, że bower nie ma polityki dotyczącej korzystania z html, css i javascript. npm również nie ma żadnej polityki poza tym, że prawie wszystko na npm jest napisane, aby przynajmniej obsługiwać commonjs, a czasami także inne formaty. Możesz umieścić html i css w pakietach npm, tak jak w przypadku bower. Na npm istnieje wiele pakietów tylko frontendowych, w tym pakiety zawierające css i html.
zastępstwo

3
Jeśli używasz browserify , npm jest idealnym menedżerem pakietów. Myślę, że nie ma znaczenia, którego menedżera pakietów używasz, ale osobiście wolałbym tylko jeden na projekt.
Eruant

72

altana

Jest nadal bardzo popularny wśród programistów front-end, mimo że ma bardzo niewiele funkcji. Używa go każdy pakiet front-end. Istnieje również inicjatywa połączenia altany z npm .

Bower jest zoptymalizowany pod kątem klienta i obsługuje tylko płaskie drzewa zależności, tj. Każda biblioteka musi być używana tylko raz (ponieważ wysyłanie różnych wersji tej samej biblioteki do klienta jest kosztowne), a ograniczenia zależności muszą zostać rozwiązane przez użytkownika .

Możesz spodziewać się, że w rejestrze bower ( bower search <some keyword>) znajdziesz wszystko, co jest związane z front-endem - moim zdaniem jest to największa zaleta bower w stosunku do innych menedżerów pakietów.

volo

Nadal nie używałem go od ponad 5 minut od lat. Nie wiem o tym, ale z tego, co widzę , zawiera pewne narzędzie do budowania, które jest bardzo dobrze znane użytkownikom Grunt.

npm

Tak, npm to skrót od Node Package Manager. Ale w dzisiejszych czasach możesz go używać do wszystkiego; ludzie nie tylko zajmują npm installsię rzeczami i oczekują, że będą działać tylko w środowisku Node. Na przykład istnieje wiele pakietów npm dla Twitter Bootstrap .

Npm jest zoptymalizowany pod kątem użycia po stronie serwera, z zagnieżdżonym drzewem zależności. Każda zależność może mieć własne zależności, które mogą mieć własne i tak dalej. To wyeliminowało konflikty wersji zależności, ponieważ każda zależność może używać własnej wersji, np. Podkreślenia. Jednak nadchodząca wersja 3 npm spłaszczy drzewo zależności :

Z npm @ 3, twój katalog node_modules będzie dużo bardziej płaski. Wszystkie twoje zależności i większość twoich zależności podrzędnych (i (pod) + zależności) będzie siedzieć obok siebie na najwyższym poziomie. Tylko wtedy, gdy wystąpią konflikty, moduły zostaną zainstalowane na głębszych poziomach. Powinno to znacznie ułatwić pracę użytkownikom systemu Windows.

Niektóre zalety, które widzę przy korzystaniu z npm:

  • Jest używany przez wszystkie inne menedżery pakietów (komponent, bower, volo, JSPM itp.);
  • Pozwala na używanie skryptów budowania;
  • Dostępnych jest wiele narzędzi do introspekcji pakietów opartych na npm

npm to menedżer pakietów dla JavaScript.

Zrzut ekranu npmjs.com


Od lutego 2013 roku moja opinia była następująca. Proszę, nie bierz tego już pod uwagę.

npm

Lepiej trzymać się tego, gdy jesteś z projektem Node, jest bardzo niewiele projektów, które są również dostępne dla przeglądarek ...

altana

Bower jest teraz popowym facetem. Mają wiele projektów pod maską, a opiekunowie projektów lubią aktualizować je w rejestrze altan ...

Szkoda, że ​​czasami jest trochę wadliwy.

volo

Od tamtej pory nie próbowałem volo dłużej niż 5 minut, ale z tego co widziałem wygląda na bardziej elastyczne niż altana.

Wadą volo jest to, że ich projekty są bardzo przestarzałe.


19
Na npm istnieją tysiące modułów, które działają tylko w przeglądarkach lub działają zarówno w węźle, jak iw przeglądarkach. Wielu z nich ma nawet identyfikatory ci, które dokładnie informują, w jakich przeglądarkach pracują. Większość informacji na temat bower et wszystko prawdopodobnie jest na npm.
zastępstwo

Nie rozumiem potrzeby, aby projekt taki jak ngBoilerplate używał altany, podczas gdy to już zależy od npm do instalacji
lolski

5
Co to jest "popowy facet"? Czy „pop” to skrót. dla „popularne”?
Bryan Oakley,

4
Na twoim zrzucie ekranu npm oznacza podręcznik planowania nuklearnego;)
Jim Jones

24

Wydaje się, że rozwiązują ten sam problem, ale dla różnych środowisk / światów. NPM dla nodejs i volo, bower dla przeglądarki.

Prawda jest taka, że ​​NPM można używać również do zarządzania javascript i css w przeglądarce. Nic nie stoi na przeszkodzie, abyś to zrobił. W tym sensie używanie NPM wydaje mi się bardziej naturalne niż konieczność zarządzania dwoma różnymi narzędziami do tego samego celu.

Wygląda na to, że bower ma więcej dostępnych pakietów, przynajmniej dla tych bardziej popularnych. Ale wkrótce jQuery będzie również dostępne bezpośrednio w NPM i prawdopodobnie wszystkie inne biblioteki będą podążać za tym samym trendem.

Moim zdaniem, skoro istnieją narzędzia takie jak browserify i webmake , które pomagają korzystać z modułów węzłów w przeglądarce, nie ma już prawdziwej potrzeby bower lub volo , chyba że oferują coś innego dla ciebie (konkretny moduł istniejący tylko w ich rejestry).

Zarówno Volo, jak i Bower też są dobre, ale z mojego punktu widzenia, jeśli już używasz NPM, lepiej będzie się tego trzymać.

Pamiętaj, że możesz używać NPM do zarządzania zależnościami klientów nawet bez korzystania z browserify lub webmake . W większości projektów, nad którymi pracuję, po zainstalowaniu modułów npm uruchamiam skrypt, aby wdrożyć je w miejscu, w którym moja aplikacja kliencka ich używa. Czasami używam grunt, aby połączyć ten plik z innymi plikami js, a czasami odwołuję się do niego bezpośrednio z plików szablonów moich aplikacji internetowych. W każdym razie jest to osobiste preferencje. Inni mogą uznać, że Bower lub Volo są łatwiejsze w użyciu, ponieważ są bardziej naturalne w ich przepływie pracy.


1
Dobrze jest mieć konkurencyjne rozwiązania tego samego problemu. Masz jakiś pomysł, dlaczego yeomanprojekt zdecydował się wymyślić nowego menedżera pakietów, skoro już go mieliśmy npm? (To było dojrzałe, sławne i bogate w funkcje) Ta myśl sprawia, że ​​czuję, że wciąż nie rozumiem.
Yugal Jindle

1
Niezupełnie, ale jak powiedziałeś, czasami zabawne jest wymyślanie koła na nowo, tylko dlatego, że możesz, a czasami robiąc to, wprowadza się pewne ulepszenia, próbując rozwiązać ten sam problem. Nie do końca dlaczego zdecydowali się stworzyć nowy, poza tym, że ułatwiają programistom frontendowym znajdowanie pakietów. Nie wszyscy deweloperzy frontendu mają doświadczenie w pracy z węzłami, myślę, że to jest główny powód projektów takich jak Bower. Postaraj się ułatwić użytkownikom bez węzłów, zgaduję tutaj.
roy riojas

Myślę, że chcieli oddzielić kłopoty npmna rzecz prostoty frontendu. Stąd do rozwoju frontendu.
Yugal Jindle

15

Dużą zaletą Bowera nad NPM jest to, że jego zarządzanie zależnościami wymusza używanie pojedynczej wersji komponentu (podczas gdy NPM działa poprzez posiadanie różnych kopii / wersji jako zależności zależnych różnych modułów). Jest to BARDZO DOBRA RZECZ, ponieważ zapobiega to nadymaniu javascript po stronie klienta z powodu konieczności dołączania wielu kopii komponentu w różnych wersjach. Dołączenie wielu kopii modułu ma kluczowe znaczenie dla działania zarządzania zależnościami NPM, dlatego NPM jest całkowicie nieodpowiedni do zarządzania pakietami po stronie klienta.

Konsekwencją powyższego jest to, że opiekunowie pakietów i konsumenci bower muszą bardziej uważać na utrzymywanie numerów wersji zależności, aby uniknąć konfliktów, ale jest to cena, którą warto zapłacić. I uważam, że moduły NPM są często niechlujne w wydawaniu głównych, mniejszych i poprawek, więc zarządzanie zależnościami NPM również nie jest dokładnie usłane różami.


3
Dzieje się tak tylko wtedy, gdy udostępniasz swój kod frontendu bezpośrednio z folderu, w którym menedżer pakietów umieścił te pliki. W moim przypadku albo mam skrypt kompilacji do przetwarzania plików less / js albo browserify, aby utworzyć pakiet z tych plików. Więc to nie jest duży problem w moim przypadku. Dystrybuowany kod zawsze ma właściwe wersje, nawet jeśli inne podkomponenty mogą mieć duplikaty podczas programowania, nigdy nie trafią do produkcji.
roy riojas

nawet jeśli nieumyślnie wymagasz (jako zależności zależnych) dwóch różnych wersji tej samej zależności? Myślę, że w tym przypadku mylisz
wheresrhys

Zwykle nie potrzebuję modułów, których nie kontroluję, więc zawsze będą te właściwe ... jeśli przypadkowo moduł spróbuje zażądać danego modułu z podkładek, kompilacja się nie powiedzie. Nie ma sensu używać altany w moim przypadku, nie ma żadnych korzyści
roy riojas

Można więc bezpiecznie powiedzieć, że npm pozwala uniknąć duplikowania modułów w kodzie po stronie klienta, jeśli masz kontrolę nad całym drzewem zależności. Z pewnością tak nie jest w przypadku zdecydowanej większości rzeczy, nad którymi pracuję, i prawdopodobnie nie w przypadku większości projektów wykorzystujących menedżera zależności w celu włączenia modułów po stronie klienta.
wheresrhys

1
O ile nie pracujesz nad mashupami, twoje drzewo zależności nie będzie tak skomplikowane, przynajmniej w przypadku kodu innej firmy. Większość bibliotek js eksportuje jedną globalną, więc używając browserify-shim, możesz upewnić się, że możesz ich używać z zakresu globalnego, stąd zawsze wersja, którą kontrolujesz. Chodzi mi o to, że możesz osiągnąć to samo bez potrzeby posiadania innego menedżera pakietów oprócz tego, który już masz. W końcu może to być kwestia preferencji. Zawsze trzeba iść na kompromis.
roy riojas

5

Wiem, że to nie jest objęte zakresem pytania, ale jest też inna alternatywa. Jam JS - http://jamjs.org/ Jedną z interesujących rzeczy jest to, że ma możliwości gruntowania w jamie:

jam compile output.js

Ktoś powinien stworzyć kolejnego menedżera pakietów i nazwać go: yapm :)


5
Twoje życzenie zostało spełnione: github.com/rlidwka/yapm : P
alex

1
Cóż, myślałem o menedżerze zależności po stronie przeglądarki, ale myślę, że to działa dla obu: p Dlatego nie mogę robić start-upów, wszystkie moje pomysły były już przemyślane.
Bruce Lim

@BruceLim tak, za każdym razem, gdy myślimy, że mamy dobry pomysł, zawsze są inni ludzie, którzy już go mają.
Evan Hu
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.