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


Jaka jest zasadnicza różnica między bower i npm? Po prostu chcesz coś prostego i prostego. Widziałem, jak niektórzy z moich kolegów korzystają bower i npm wymiennie w swoich projektach.


1612
2017-09-05 16:53


pochodzenie


Powiązana odpowiedź stackoverflow.com/a/21199026/1310070 - sachinjain024
możliwy duplikat Zarządzanie zależnościami Javascript: npm vs altana vs volo? - anotherdave
Odpowiedź na to pytanie wydaje się przestarzała. Czy ktoś może nam powiedzieć, co robić w 2016 roku, jeśli używamy npm 3, który obsługuje zależność od mieszkania? Jaka jest różnica wince npm3 i altance i jaka jest teraz najlepsza praktyka? - amdev
Bottom-line, @amdev: altówka jest teraz przestarzała. npm (lub Przędza, która jest tylko niewielką różnicą) jest tam, gdzie jest. Nie jestem świadomy żadnej realnej alternatywy. - XML


Odpowiedzi:


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

Historia

npm rozpoczęto zarządzanie modułami node.js (właśnie dlatego pakiety wchodzą w node_modules domyślnie), ale działa również na front-end, gdy jest połączony z Browserify lub WebPack.

Altana jest tworzony wyłącznie dla front-end i jest zoptymalizowany z myślą o tym.

Rozmiar repo

npm jest znacznie, dużo większy niż altana, w tym ogólny JavaScript (np country-data dla informacji o kraju lub sorts do sortowania funkcji, które można wykorzystać na przednim lub tylnym końcu).

Bower ma znacznie mniejszą liczbę pakietów.

Obsługa stylów itp

Bower obejmuje style itp.

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

Obsługa zależności

Największą różnicą jest to, że npm wykonuje zagnieżdżone zależności (ale domyślnie jest płaskie), podczas gdy Bower wymaga płaskiego drzewa zależności (kładzie na użytkownika zależność obciążenia zależnościami).

Zagnieżdżone drzewo zależności oznacza, że ​​zależności mogą mieć własne zależności, które mogą mieć 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 będzie domyślnie płaskie (oszczędność miejsca) i zagnieżdżane w razie potrzeby, np. Jeśli dwie zależności potrzebują własnej wersji Podkreślenia.

Niektóre projekty używają obu, ponieważ używają Bower dla pakietów front-end i npm dla narzędzi programistycznych takich jak Yeoman, Grunt, Gulp, JSHint, CoffeeScript itp.


Zasoby


1828
2017-09-06 08:09



Dlaczego zagnieżdżone drzewo zależności nie działa tak dobrze na pierwszym planie? - Lars Nyström
Czy frontmalny pakiet npm może nie być również płaskim drzewem zależności? Mam do czynienia z "dlaczego potrzebujemy 2 menedżerów pakietów?" dylemat. - Steven Vachon
Co rozumiesz przez "płaskie drzewo zależności"? Płaskie drzewo jest czym - lista? To nie jest drzewo. - mvmn
W rzeczywistości ścieżka jest także drzewem. To tylko szczególny przypadek. Z WikiPedia: "W matematyce, a dokładniej w teorii grafów, drzewo to niekierowany wykres, w którym dwa wierzchołki są połączone dokładnie jedną ścieżką." - Jørgen Fogh
npm 3 obsługuje teraz płaskie drzewo zależności. - vasa


Ta odpowiedź jest dodatkiem do odpowiedzi Sindre Sorhus. Główną różnicą między NPM i Bower jest sposób, w jaki traktują rekursywne zależności. Zauważ, że mogą być używane razem w jednym projekcie.

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

O wiele trudniej jest uniknąć konfliktów zależności bez zagnieżdżania się   zależności. Jest to fundamentalne dla sposobu, w jaki npm działa i ma   okazał się niezwykle skutecznym podejściem.

Na Altana strona główna:

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

W skrócie, npm ma na celu stabilność. 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ć, rekurencyjnie instaluje pewne 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 widać, że wszystkie unikalne zależności są na tym samym poziomie.

Dlaczego więc zawracać sobie głowę użyciem npm?

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 zadziała, ale Bower da ci konflikt ponieważ nie lubi duplikowania (ponieważ ładowanie tego samego zasobu na stronie internetowej 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ć awarię jednej z zależności, ale jest to coś, co i tak trzeba będzie naprawić.

Tak więc powszechnym użyciem jest Bower dla pakietów, które chcesz opublikować na swoich stronach internetowych (np. środowisko wykonawcze, w którym unikasz duplikacji) i używasz npm do innych rzeczy, takich jak testowanie, budowanie, optymalizacja, sprawdzanie itp. (np. czas rozwoju, w przypadku gdy powielanie stanowi mniejszy problem).

Zaktualizuj 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, a następnie moduł 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, proponuję przeczytać dokumenty z npm 3


338
2017-11-24 13:10



To prawie banalne, że "tworzenie oprogramowania dotyczy wyłącznie kompromisów". To jest dobry przykład. Trzeba wybrać zarówno większa stabilność z npm  lub minimalne obciążenie zasobów przy pomocy bower. - jfmercer
@Shrek Jestem bezwarunkowo stwierdzając, że faktycznie można korzystać z obu. Mają różne cele, jak stwierdzam w ostatnim akapicie. To nie jest kompromis w moich oczach. - Justus Romijn
Ahh, widzę, że źle cię zrozumiałem. Albo nie czytałem wystarczająco uważnie. Dziękuję za wyjaśnienie. :-) To dobrze, że oba mogą być używane bez kompromisu. - jfmercer
@AlexAngas Dodałem aktualizację dla npm3. Wciąż ma pewne poważne różnice w porównaniu z Bower. npm prawdopodobnie zawsze będzie obsługiwać wiele wersji zależności, a Bower nie. - Justus Romijn
npm 3 zbliża się do altany;) - ni3


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

Myślę, że poprzednie plakaty poruszyły niektóre z podstawowych wyróżnień. (Wykorzystanie zagnieżdżonych zależności npm jest bardzo pomocne w zarządzaniu dużymi, złożonymi aplikacjami, chociaż nie uważam, że jest to najważniejsze rozróżnienie).

Zaskoczyło mnie jednak, że nikt nie wyjaśnił jednoznacznie jednego z najbardziej fundamentalnych rozróżnień między Bower i 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 po prostu różnica w składni.

Ale to rozróżnienie moduły vs. globały (lub moduły vs. "skrypty") jest prawdopodobnie najważniejszą różnicą między Bower i NPM. Podejście npm do umieszczenia wszystkiego w modułach wymaga zmiany sposobu pisania Javascriptu dla przeglądarki, prawie na pewno na lepsze.

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

W wersji root Bower zajmuje się ładowaniem zwykłych starych plików skryptów. Niezależnie od tych plików skryptów, Bower załaduje je. Co w zasadzie oznacza, że ​​Bower jest tak samo jak wszystkie twoje skrypty w prostym stylu <script>jest w <head> twojego kodu HTML.

Tak samo, jak do tej samej podstawowej metody, do której jesteś przyzwyczajony, ale dostajesz kilka fajnych udogodnień automatyzacji:

  • Kiedyś musisz uwzględnić zależności JS w repozytorium projektu (podczas rozwijania) lub uzyskać je przez CDN. Teraz możesz pominąć tę dodatkową wagę pobierania w repozytorium, a ktoś może zrobić szybki bower installi natychmiast mają to, czego potrzebują, lokalnie.
  • Jeśli zależność Bower określa w niej swoje własne zależności bower.jsonTe też zostaną pobrane dla ciebie.

Ale poza tym, Bower nie zmienia tego, jak piszemy javascript. Nic, co wchodzi w pliki ładowane przez Bowera, w ogóle się nie zmienia. W szczególności oznacza to, że zasoby dostarczone w skryptach załadowanych przez Bower (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, jawny iniekcja zależności

Cały kod w Node land (a więc cały kod ładowany przez npm) ma strukturę modułów (konkretnie, jako implementacja Format modułu CommonJSlub 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), skonstruujesz swój kod w taki sam sposób, jak robi to Node.

Bardziej inteligentni ludzie niż ja zajęli się kwestią "Dlaczego moduły?", Ale oto podsumowanie kapsuły:

  • Wszystko w module jest efektywne z nazwami, co oznacza, że ​​nie jest już zmienną globalną i nie można jej przypadkowo odwołać bez zamiaru.
  • Wszystko, co znajduje się wewnątrz modułu, musi zostać celowo wstrzyknięte do określonego kontekstu (zwykle innego modułu), aby móc z niego skorzystać
  • Oznacza to, że możesz mieć wiele wersji tej samej zależności zewnętrznej (np. Lokaj) 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żywać jednej wersji zależności, ale jedna z twoich zewnętrznych zależności określa inną, która powoduje konflikty, lub masz dwie zewnętrzne zależności, z których każda chce innej wersji.)
  • Ponieważ wszystkie zależności są ręcznie wprowadzane 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 świadomie postanowiłem tu wstrzyknąć".
  • Bo nawet zawartość wstrzykiwanych modułów jest enkapsulowany za zmienną, do której ją przypisujesz, a cały kod wykonuje się 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ą bez twojej świadomości, lub że to zrobisz. (To mogą zdarzają się, ale zazwyczaj musisz zrobić coś, żeby to zrobić, z czymś podobnym window.variable. Nadal zdarza się jeden wypadek, który się zdarza this.variable, nie zdając sobie z tego sprawy this jest aktualne window w obecnym kontekście.)
  • Kiedy chcesz przetestować indywidualny moduł, możesz łatwo wiedzieć: dokładnie, co jeszcze (zależności) wpływa na kod, który działa wewnątrz modułu? A ponieważ wyraźnie wstrzykujesz wszystko, możesz łatwo kpić z tych zależności.

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


Aby nauczyć się korzystać ze składni modułu CommonJS / Node, potrzeba około 30 sekund. Wewnątrz danego pliku JS, który ma być modułem, najpierw zadeklarujesz wszystkie zewnętrzne zależności, których chcesz użyć, na przykład:

var React = require('react');

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

Na końcu pliku eksportujesz wszystko, co chcesz udostępnić całemu światu, na przykład:

module.exports = myModule;

Następnie, aby użyć przepływu pracy opartego na CommonJS w przeglądarce, użyjesz narzędzi takich jak Browserify do przechwycenia wszystkich tych pojedynczych plików modułów, enkapsulacji ich zawartości w środowisku wykonawczym i wstrzyknięcia ich do siebie w razie potrzeby.

ORAZ, ponieważ moduły ES6 (które prawdopodobnie przejdziesz na ES5 z Babel lub podobnym) zyskują szeroką akceptację i pracują zarówno w przeglądarce, jak iw Węźle 4.0, powinniśmy wspomnieć o dobry przegląd także tych.

Więcej informacji o wzorach do pracy z modułami ta talia.


EDYCJA (luty 2017): Facebook Przędza jest bardzo ważnym potencjalnym zamiennikiem / uzupełnieniem npm: szybkie, deterministyczne, zarządzanie pakietami offline, które opiera się na tym, co daje tobie. Warto sprawdzić każdy projekt JS, szczególnie, że tak łatwo jest go zamienić.


256
2017-07-26 03:12



Cieszę się, że ta odpowiedź była tutaj, inne popularne odpowiedzi nie wspominają o tym szczególe. npm zmusza cię do pisania kodu modularnego. - Juan Mendes


Aktualizacja na okres od 2017 do października

W końcu Bower przestarzałe. Koniec opowieści.

Starsza odpowiedź

Od Mattias Petter Johansson, programisty JavaScript w Spotify:

W prawie wszystkich przypadkach lepiej jest używać Browserify i npm zamiast Bower. Jest to po prostu lepsze rozwiązanie do pakowania dla aplikacji front-end niż Bower. W Spotify używamy npm do pakowania całych modułów WWW (html, css, js) i działa bardzo dobrze.

Bower jest marką jako menedżer pakietów w Internecie. Byłoby wspaniale, gdyby to było prawdą - menedżer pakietów, który poprawiłby moje życie, jako że front-end developer byłby niesamowity. Problem polega na tym, że Bower nie oferuje specjalistycznych narzędzi do tego celu. Nie oferuje żadnych narzędzi, o których wiem, że npm nie ma, a zwłaszcza tych, które są szczególnie przydatne dla programistów front-end. Po prostu nie ma żadnej korzyści dla programisty front-endowego, który używałby Bowera na npm.

Powinniśmy przestać używać altany i konsolidować wokół npm. Na szczęście to właśnie dzieje się:

Module counts - bower vs. npm

Dzięki przeglądarce lub pakietowi internetowemu bardzo łatwo jest połączyć wszystkie swoje moduły w duże, zminiaturyzowane pliki, co jest niesamowite pod względem wydajności, szczególnie w przypadku urządzeń mobilnych. Nie tak z Bower, co wymaga znacznie więcej pracy, aby uzyskać ten sam efekt.

npm oferuje również możliwość jednoczesnego korzystania z wielu wersji modułów. Jeśli nie zrobiłeś wiele rozwoju aplikacji, może to początkowo uderzyć cię jako coś złego, ale po przejściu kilku ataków Piekło zależne zrozumiesz, że posiadanie wielu wersji jednego modułu jest bardzo dobrą cechą. Zauważ, że npm zawiera bardzo przydatne narzędzie dedupe automatycznie upewnia się, że używasz tylko dwóch wersji modułu, jeśli faktycznie mieć na - jeśli dwa moduły oba mogą użyj tej samej wersji jednego modułu, będą. Ale jeśli oni żargon, masz bardzo przydatny.

(Zauważ, że Webpack i rollup są powszechnie uważane za lepsze niż Browserify od sierpnia 2016 r.)


117
2017-07-04 10:48



webpack i npm są jeszcze lepsze, myślę, że ... - refactor
<sarkazm> Należy pamiętać, że nawet projekt typu "cześć świat" wymaga 300+ modułów do uruchomienia ... </ sarkazm>: O - Mariusz Jamro
Nie zgadzam się z tym, że "duże, zminimalizowane pliki" są "niesamowite pod względem wydajności, zwłaszcza w przypadku urządzeń mobilnych". Wręcz przeciwnie: ograniczona przepustowość wymaga małych plików, ładowanych na żądanie. - Michael Franzl
Niezbyt dobra rada. Większość pakietów npm to tylko backend nodejs. Jeśli nie robisz javascript na zapleczu, lub nie masz systemu modułów w miejscu, liczba pakietów jest nieistotna, ponieważ Bower będzie lepiej odpowiadał twoim potrzebom - Gerardo Grignoli
@GerardoGrignoli: altanka jest już w drodze. - Dan Dascalescu


Bower utrzymuje pojedynczą wersję modułów, próbuje jedynie pomóc ci wybrać właściwą / najlepszą dla Ciebie.

Zarządzanie zależnościami Javascript: npm vs altana 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 jest tylko zasięg globalny i chcesz być bardzo selektywny w stosunku do wersji, z którą pracujesz.


43
2017-07-19 20:59



Czuję, że Sindre wspomina to, gdy mówi o zagnieżdżonej zależności. - Games Brainiac
@GamesBrainiac twój poprawny, po prostu pomyślałem, że umieściłbym to w moich własnych słowach. - Sagivf
@Sagivf Są to NIE twoje własne słowa, chyba że jesteś także wheresrhys, który dostarczył oryginalną odpowiedź tutaj - dayuloli
@Sagivf Nie ma nic złego w kopiowaniu ** odpowiednie części odpowiedzi innych, jeśli sami tutaj nie udzielili odpowiedzi. Po prostu podsunęło mi to trochę, że powiedziałeś "po prostu pomyślałem, że umieściłbym to w moich własnych słowach". Kredyt powinien trafić tam, gdzie jest należny kredyt. - dayuloli
Nie wiem, dlaczego tak bardzo nabraliście tej odpowiedzi. W tej odpowiedzi jest rzeczywiście nowa informacja / perspektywa. - Calvin


Mój zespół przeniósł się z Bower i przeprowadził migrację do npm, ponieważ:

  • Programatyczne korzystanie było bolesne
  • Interfejs Bower ciągle się zmieniał
  • Niektóre funkcje, takie jak skrót adresu URL, są całkowicie zepsute
  • Używanie zarówno Bowera, jak i npm w tym samym projekcie jest bolesne
  • Trzymanie pola wersji bower.json zsynchronizowane z tagami git jest bolesne
  • Kontrola źródła! = Zarządzanie pakietami
  • Wsparcie CommonJS nie jest proste

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


31
2018-02-16 21:04





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

Z jednej strony utworzono npm, aby zainstalować moduły używane w środowisku node.js lub narzędzia programistyczne zbudowane przy użyciu node.js, takie jak karma, lint, minifiery i tak dalej. npm może instalować moduły lokalnie w projekcie (domyślnie w module 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 zawierającego listę zależności. Ta lista jest rozpoznawana przez npm po uruchomieniu npm install, który następnie pobiera i instaluje je dla ciebie.

Z drugiej strony stworzono altanę do zarządzania zależnościami frontendu. Biblioteki takie jak jQuery, AngularJS, podkreślenia itp. Podobnie jak npm ma plik, w którym można określić listę zależności o nazwie bower.json. W tym przypadku twoje zależności frontendu są instalowane przez instalację bower install, która 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
2017-10-03 00:08



Z nadejściem npm dedupe, jest to nieco przestarzałe. Widzieć Odpowiedź Mattias. - Dan Dascalescu


Dla wielu osób pracujących z node.js główną zaletą altruszy jest zarządzanie zależnościami, które w ogóle nie są javascriptem. Jeśli pracują z językami kompilującymi do javascript, npm może być używany 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ą do javascript mogą mieć dziwne manglingowanie języka źródłowego, które sprawia, że ​​przekazywanie ich do kompilacji do javascript jest nieelegancką opcją, gdy użytkownicy oczekują kodu źródłowego.

Nie wszystko w pakiecie npm musi być javascriptem skierowanym do użytkownika, ale w przypadku pakietów biblioteki npm przynajmniej część z nich powinna być.


4
2017-10-11 20:42



Ten wpis na blogu npmjs stwierdza: "Twój pakiet może zawierać wszystko, niezależnie od tego, czy jest to ES6, JS po stronie klienta, czy nawet HTML i CSS. Są to rzeczy, które naturalnie pojawiają się wraz z JavaScriptem, więc umieść je tam.". - Dan Dascalescu
Istnieje różnica między może zawierać, i powinno zawierać. Oczywiście mogą zawierać wszystko, ale ogólnie rzecz biorąc, one powinno zawierać jakiś rodzaj interfejsu do commonJS. W końcu jest to "menedżer pakietów węzłów". Część o Są to rzeczy, które naturalnie pojawiają się wraz z Javascriptem


Bower i Npm to menedżerowie pakietów dla javascript.

Altana

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

Bower ma plik konfiguracyjny o nazwie bower.json. W tym pliku możemy zachować konfigurację dla Bower, która jest zależna od potrzeb i szczegółów licencji, opisu, nazwy i tak dalej. Bower nadaje się do pakietów front-end takich jak jquery, angle, react, ember, nokaut, kręgosłup i tak dalej.

Npm

Npm jest najczęściej używana do zarządzania modułami Node.js, ale działa również na front-end. Używa zagnieżdżonego drzewa zależności oraz drzewa zależności płaskich. Jest popularny i ma wielu współpracowników. Nowa wersja zawsze oferuje ekscytujące funkcje.

Npm ma plik konfiguracyjny o nazwie package.json. W tym pliku możemy zachować konfigurację dla Npm, takie jakich potrzebujemy zależności i szczegóły licencji, opis, nazwę i tak dalej. Npm zapewnia zależności i zależności. 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 inne.

To oczywiście nie działa tak dobrze na front-end, ponieważ potrzebujemy jQuery w naszych projektach. Potrzebna jest tylko jedna kopia jQuery, ale gdy inny pakiet wymaga jQuery, pobierze ponownie jeszcze jedną kopię jQuery. Jest to jedna z głównych wad Npm.

Kluczowa uwaga: Powodem, dla którego wiele projektów korzysta z obu jest to, że używają Bower dla pakietów front-end i Npm dla narzędzi programistycznych. Pomnożenie menedżera pakietów w projekcie powoduje, że przepływ pracy jest trudniejszy. Npm 3 w połączeniu z browserify lub pakiet internetowy to jest teraz droga.


1
2018-01-07 09:26