8 Soru: Bower ve npm arasındaki fark nedir?

tarafından oluşturulan soru Thu, Mar 2, 2017 12:00 AM

bower ve npm arasındaki temel fark nedir? Sadece sade ve basit bir şey istiyorum. İş arkadaşlarımdan bazılarının projelerinde bower ve npm'u birbirinin yerine kullandığını gördüm.

    
1696
  1. 2014-03-19 12: 54: 55Z
  2. 2014-07-24 15: 47: 03Z
  3. Bu sorunun cevabı eski görünüyor. Düz bağımlılığı destekleyen npm 3 kullanıyorsak, biri bize 2016'da ne yapacağımızı söyleyebilir mi? Npm3 ile bower arasındaki fark nedir ve şu anda en iyi uygulama nedir?
    2016-10-05 11: 48: 01Z
  4. Alt satır, @ amdev: bower artık kullanımdan kaldırıldı. npm (veya sadece küçük bir fark olan iplik) bulunduğu yer. Uygun alternatiflerin farkında değilim.
    2018-01-07 15: 32: 00Z
8 Yanıtlar                              8                         

Tüm paket yöneticilerinin pek çok dezavantajı vardır. Sadece birlikte yaşayabileceğinizi seçmek zorundasınız.

Geçmiş

npm , node.js modüllerini yönetmeye başladı (bu nedenle paketler varsayılan olarak node_modules’a çıkıyor) Ön uç için de Browserify veya WebPack ile birlikte kullanıldığında.

Bower , yalnızca ön uç için yaratılmıştır ve bunu düşünerek optimize edilmiştir.

Repo boyutu

npm, genel amaçlı JavaScript (ülke bilgileri için country-data veya ön uç veya arka uçta kullanılabilen işlevleri sıralama için sorts gibi) dahil, çok daha büyüktür.

Bower çok daha az miktarda pakete sahip.

Stillerin işlenmesi vs.

Bower stilleri içerir vb.

npm, JavaScript'e odaklanmıştır. Stiller ya ayrı ayrı indirilir ya da npm-sass ya da sass-npm gibi bir şey gerektirir.

Bağımlılık yönetimi

En büyük fark, npm'nin yuvalanmış bağımlılıkları yapmasıdır (ancak varsayılan olarak düzdür), Bower düz bir bağımlılık ağacı gerektirir (bağımlılık çözme yükünü kullanıcıya yükler) .

Yuvalanmış bir bağımlılık ağacı, bağımlılıklarınızın, kendilerine ait olan kendi bağımlılıklarına sahip olabileceği anlamına gelir. Bu, iki modülün aynı sıkıntının farklı sürümlerini gerektirmesini ve hala çalışmasını sağlar. Npm v3'ten beri, bağımlılık ağacı varsayılan olarak düz olacaktır (yerden tasarruf) ve yalnızca gerektiğinde yuva yapar; örneğin, iki bağımlılık kendi alt çizgi sürümüne ihtiyaç duyarsa.

Bazı projeler, her ikisini de kullanır; Bower'ı ön uç paketler için kullanır ve npm, Yeoman, Grunt, Gulp, JSHint, CoffeeScript, vb. gibi geliştirici araçlar için


Kaynaklar

1879
2018-06-29 11: 57: 23Z
  1. Neden iç içe geçmiş bir bağımlılık ağacı bunu ön tarafta iyi yapmıyor?
    2014-01-19 16: 41: 09Z
  2. Bir ön uç npm paketi de düz bir bağımlılık ağacı olamaz mı? "Neden 2 paket yöneticisine ihtiyacımız var?" İle karşı karşıyayım. ikilem.
    2014-01-24 02: 51: 36Z
  3. "Yassı Bağımlılık Ağacı" ile ne demek istiyorsunuz? Düz ağaç nedir - bir liste? O zaman bir ağaç değil.
    2014-10-17 02: 42: 58Z
  4. Aslında bir yol da bir ağaç. Bu sadece özel bir durum. WikiPedia'dan: "Matematikte ve daha özel olarak grafik teorisinde bir ağaç, herhangi iki köşenin tam olarak bir yolla bağlandığı yönlendirilmemiş bir grafiktir."
    2014-12-25 17: 20: 44Z
  5. npm 3 şimdi düz bir bağımlılık ağacını destekliyor.
    2015-11-21 06: 55: 44Z

Bu cevap, Sindre Sorhus'un cevabına bir ektir. Npm ve Bower arasındaki en büyük fark, özyinelemeli bağımlılıkları tedavi etme şeklidir. Tek bir projede birlikte kullanılabileceklerini unutmayın.

npm SSS : (6 Eylül 2015 tarihli archive.org bağlantısı)

  

Bağımlılık çakışmalarını iç içe geçmeden önlemek çok daha zor   bağımlılıklar. Bu, npm'nin çalışma şeklinin temelini oluşturur ve   son derece başarılı bir yaklaşım olduğu kanıtlandı.

Bower ana sayfasında:

  

Bower ön uç için optimize edilmiştir. Bower düz bir bağımlılık kullanır   ağaç, her paket için yalnızca bir sürüm gerektiren sayfa yükünü azaltır   en azından.

Kısacası, npm istikrarı amaçlar. Bower, minimum kaynak yükü hedefliyor. Bağımlılık yapısını çizerseniz, şunu göreceksiniz:

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

Gördüğünüz gibi, bazı bağımlılıkları tekrar tekrar yükler. Bağımlılık A'nın yüklü üç örneği var!

Bower:

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

Burada tüm benzersiz bağımlılıkların aynı seviyede olduğunu görüyorsunuz.

Öyleyse, npm kullanarak neden rahatsız etmiyorsunuz?

Belki B bağımlılığı, A bağımlılığının C bağımlılığından farklı bir versiyonunu gerektirir. npm, bu bağımlılığın her iki versiyonunu da kurar, böylece yine de çalışacaktır, fakat Bower, size bir çatışması verir çünkü çoğaltmayı sevmez. (aynı kaynağın bir web sayfasına yüklenmesi çok verimsiz ve maliyetli olduğundan, bazı ciddi hatalar da verebilir). Hangi sürümü kurmak istediğinizi elle seçmeniz gerekecektir. Bu, bağımlılıklardan birinin kırılmasına neden olabilir, ancak bu yine de düzeltmeniz gereken bir şeydir.

Bu nedenle, ortak kullanım web sayfalarınızda yayınlamak istediğiniz paketler için Bower’dır (örneğin, çoğaltılmayı önlemek istediğiniz yerlerde çalışma zamanı ) ve test etmek, oluşturmak gibi diğer şeyler için npm kullanın, optimize etme, kontrol etme, vb. (örneğin, çoğaltmanın daha az endişeli olduğu geliştirme süresi ).

Npm 3 için güncelleme:

npm 3, Bower'a kıyasla hala farklı şeyler yapıyor. Bağımlılıkları global olarak kuracaktır, ancak karşılaştığı ilk sürüm için. Diğer sürümler ağaca kurulur (ana modül, sonra node_modules).

  • [node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (kök sürümünü kullanır)
    • dep C v1.0
      • dep A v2.0 (bu sürüm kök sürümden farklıdır, bu nedenle yuvalanmış bir yükleme olacaktır)

Daha fazla bilgi için npm 3 belgelerini okumayı öneririm

    
356
2018-07-05 13: 33: 22Z
  1. Artık neredeyse "yazılım geliştirme tamamen değiş tokuşlarla ilgili" bir klişe. Bu iyi bir örnektir. Birinin npm ile ya daha fazla kararlılık ya da bower ile en az kaynak yükü seçilmesi gerekiyor.
    2015-06-10 00: 38: 17Z
  2. @ Shrek Öyle ya da her ikisini de kullanabileceğinizi belirtiyorum. Son paragrafta belirttiğim gibi farklı amaçları var. Bu gözlerimdeki bir takas değil.
    2015-06-10 08: 25: 10Z
  3. Ahh, sizi yanlış anladım. Ya da yeterince dikkat etmedim. Açıklama için teşekkürler. :-) Her ikisinin de takas olmadan kullanılabileceği iyi bir şey.
    2015-06-10 14: 38: 44Z
  4. @ AlexAngas npm3 için bir güncelleme ekledim. Bower ile karşılaştırıldığında hala bazı büyük farklılıklar var. npm muhtemelen her zaman birden fazla bağımlılık sürümünü destekleyecektir, oysa Bower bunu yapmaz.
    2016-01-18 10: 13: 38Z
  5. npm 3, kuşatmaya yaklaşıyor;)
    2017-03-21 06: 40: 19Z

TL; DR: Günlük kullanımdaki en büyük fark iç içe bağımlılıklar değildir ... bu modüller ve geneller arasındaki farktır.

Önceki posterlerin bazı temel ayrımları iyi ele aldığını düşünüyorum. (npm'nin iç içe bağımlılık kullanımı, en önemli ayrım olduğunu düşünmeme rağmen, büyük ve karmaşık uygulamaların yönetilmesinde gerçekten çok faydalıdır.)

Ancak, hiç kimsenin Bower ve npm arasındaki en temel ayrımlardan birini açıkça açıklamadığını şaşırttı. Yukarıdaki cevapları okursanız, sık sık npm bağlamında kullanılan 'modüller' kelimesini görürsünüz. Fakat sözdizimi farkı olsa bile, sanki rasgele bahsedilir.

Ancak modüller - globals (veya modüller - 'komut dosyaları') arasındaki bu ayrım muhtemelen Bower ve npm arasındaki en önemli farktır. Her şeyi modüllere koymanın npm yaklaşımı, tarayıcı için Javascript'i yazma şeklini değiştirmenizi gerektirir, neredeyse kesinlikle daha iyisi için.

Bower Yaklaşımı: <script> Etiketleri gibi Küresel Kaynaklar

Kökte, Bower düz eski komut dosyalarını yüklemekle ilgilidir. Bu script dosyalarında ne varsa, Bower bunları yükleyecektir. Bu temelde Bower'ın tüm komut dosyalarınızı HTML'nizin <script>'unda düz eski <head>'lara dahil etmek anlamına geldiği anlamına gelir.

Öyleyse, alışkın olduğunuz aynı temel yaklaşım, ancak bazı güzel otomasyon kolaylıkları elde edersiniz:

  • Eskiden proje bağımlılığınıza JS bağımlılıkları eklemeniz gerekiyordu (geliştirirken) ya da CDN yoluyla edindiniz. Artık, depodaki ekstra indirme ağırlığını atlayabilirsiniz; biri hızlı bir bower install yapabilir ve anında yerel olarak ihtiyaç duydukları şeye sahip olabilir.
  • Bir Bower bağımlılığı, bower.json'da kendi bağımlılıklarını belirtirse, bunlar da sizin için indirilir.

Ancak bunun ötesinde, Bower, javascript'i yazma biçimimizi değiştirmez . Bower tarafından yüklenen dosyaların içine nelerin girdiğiyle ilgili hiçbir şeyin değişmesi gerekmez. Bu, Bower tarafından yüklenen komut dosyalarında sağlanan kaynakların (genellikle, ancak her zaman değil), tarayıcı yürütme bağlamındaki herhangi bir yerden erişilebilecek genel değişkenler olarak tanımlanacağı anlamına gelir.

npm Yaklaşımı: Ortak JS Modülleri, Açık Bağımlılık Enjeksiyonu

Düğüm ülkesindeki tüm kodlar (ve böylece npm aracılığıyla yüklenen tüm kodlar) modüller olarak yapılandırılmıştır (özellikle

'Neden modüller?' sorusuyla ilgilendiğimden daha akıllı insanlar, ancak işte bir kapsül özeti:

  • Bir modül içindeki herhangi bir şey etkili bir şekilde ad alanına sahiptir , yani artık global bir değişken değildir ve yanlışlıkla istemeksizin referans veremezsiniz.
  • Bir modülün içindeki herhangi bir şey, onu kullanabilmek için bilerek belirli bir içeriğe (genellikle başka bir modül) enjekte edilmelidir
  • Bu, uygulamanızın çeşitli bölümlerinde aynı dış bağımlılığın birden fazla versiyonuna sahip olabileceğiniz anlamına gelir (lodash, diyelim). (Bu, şaşırtıcı bir şekilde gerçekleşir, çünkü kendi kodunuz bir bağımlılığın bir sürümünü kullanmak ister, ancak dış bağımlılıklarınızdan biri çakışan diğerini belirtir. Veya her birinin farklı bir sürüm isteyen iki dış bağımlılığı vardır.)
  • Tüm bağımlılıklar belirli bir modüle manuel olarak enjekte edildiğinden dolayı, bunlar hakkında düşünmek çok kolaydır. Bir gerçeği biliyorsunuz: "Bu konuda çalışırken göz önünde bulundurmam gereken tek kod kasıtlı olarak sahip olduğum şeydir.buraya enjekte edilmek üzere seçildi ".
  • Enjekte edilen modüllerin içeriği bile, atadığınız değişkenin arkasında kaplanmış olduğundan ve tüm kodlar sınırlı bir kapsamda yürütüldüğünde, sürprizler ve çarpışmalar çok imkansız hale gelir. Bağımlılıklarınızdan birinden birinin bir şeyi, farkında olmadan ya da böyle bir şeyi yapmadan yanlışlıkla yeniden tanımlaması muhtemeldir. ( olabilir olabilir, ancak genellikle window.variable gibi bir şeyle bunu yapmak için kendi yolunuzdan çıkmanız gerekir. Hala gerçekleşmesi muhtemel bir kaza, this.variable’un this olduğunu fark etmeden window’u atamaktır. geçerli bağlamda.)
  • Tek bir modülü test etmek istediğinizde çok kolay bir şekilde öğrenebilirsiniz: modül içerisinde çalışan kodu tam olarak başka ne (bağımlılıklar) etkiler? Ayrıca, açıkça her şeyi enjekte ettiğiniz için, bu bağımlılıklarla kolayca dalga geçebilirsiniz.

Bana göre, ön uç kod için modüllerin kullanımı aşağı doğru kayıyor: akla gelmesi ve test edilmesi kolay, daha dar bir bağlamda çalışmak ve olan bitenden daha fazla emin olmak.


CommonJS /Node modül söz diziminin nasıl kullanılacağını öğrenmek sadece 30 saniye sürer. Bir modül olacak olan belirli bir JS dosyasının içinde, ilk önce kullanmak istediğiniz herhangi bir dış bağımlılığı beyan edersiniz, şöyle:

var React = require('react');

Dosyanın /modülün içinde normalde ne yaparsanız yapın ve belki myModule olarak adlandırarak dış kullanıcılara göstermek istediğiniz bir nesne veya işlev yaratın.

Bir dosyanın sonunda, dünya ile paylaşmak istediğiniz şeyi dışa aktarırsınız, şunun gibi:

module.exports = myModule;

Ardından, tarayıcıda CommonJS tabanlı bir iş akışını kullanmak için, tüm bu ayrı ayrı modül dosyalarını almak, çalışma zamanında içeriklerini kapsüllemek ve gerektiğinde birbirlerine enjekte etmek için Browserify gibi araçlar kullanırsınız.

VE, ES6 modülleri (muhtemelen Babil veya benzerleriyle ES5’e geçiş yapacaksınız) geniş bir kabul görüyor ve hem tarayıcıda hem de Düğüm 4.0’da çalışıyor olması nedeniyle, bunlara iyi bir genel bakış .

bu güverte 'de modüller ile çalışma kalıpları hakkında daha fazla bilgi edinin.


EDIT (Şubat 2017): Facebook'un İplik bu günlerde npm için çok önemli bir potansiyel değiştirme /ekidir: hızlı, Npm'nin size ne verdiğine dayanan deterministik, çevrimdışı paket yönetimi. Herhangi bir JS projesine bakmaya değer, özellikle de içeri /dışarı değiştirmek çok kolay olduğu için.


EDIT (Mayıs 2019) "Bower nihayet kullanımdan kaldırıldı . Öykü." (h /t: @DanDascalescu, aşağıda özlü özet için.)

Ve, İplik hala etkinken , bunun için bir ivme İplik'in temel özelliklerinden bazılarını benimsedikten sonra tekrar npm'ye geri döndü.

    

264
2019-05-11 17: 41: 03Z
  1. Bu cevabın burada olduğuna sevindim, diğer popüler cevaplar bu ayrıntıdan bahsetmiyor. npm sizi modüler kod yazmaya zorlar.
    2016-05-13 13: 06: 28Z
  2. Maalesef, javascript parlands'daki tüm sıkıntılara çok az önem veren bir insandan üzgünüm, ancak küçük bir web uygulamasından yararlanan bir işletmeyi işletiyor . Son zamanlarda npm'i denemek zorunda kaldık, kahrolası ağ şeyini geliştirmek için kullandığımız araç setiyle bower kullanmaktan. Size söyleyebileceğim en büyük farkın bekleme süresi olması, npm yaşlanması. Unutmayın ki, xkcd çizgi filmini kılıcı oynayan adamlarla derlemek, patronlarına 'derlemek' diye bağırıyor; Bu, npm’in bower’a eklediği şeylerden hemen hemen fazlası.
    2018-11-21 21: 00: 25Z

2017-Ekim güncellemesi

Bower nihayet kullanımdan kaldırıldı . Hikayenin sonu.

Eski cevap

Mattias Petter Johansson'dan , Spotify şirketinde JavaScript developer:

  

Neredeyse tüm durumlarda, Browserify ve npm'yi Bower üzerinden kullanmak daha uygundur. Basitçe ön uç uygulamalar için Bower'dan daha iyi bir paketleme çözümüdür. Spotify'da, tüm web modüllerini (html, css, js) paketlemek için npm kullanıyoruz ve çok iyi çalışıyor.

     

Bower, web’in paket yöneticisi olarak kendini gösterir. Bu doğru olsaydı harika olurdu - bir ön uç geliştirici olarak hayatımı daha iyi yapan bir paket yöneticisi harika olurdu. Sorun, Bower'ın amaç için özel bir alet sunmamasıdır. Bu npm'nin bilmediğini ve özellikle ön uç geliştiriciler için özellikle yararlı olan hiçbiri bilmediğim bir takım sunuyor. Bir ön uç geliştiricinin Bower’ı npm'den fazla kullanmasına hiçbir faydası yok.

     

Bower'ı kullanmayı bırakmalı ve npm etrafında konsolide etmeliyiz. Neyse ki, bu oluyor :

 Modül sayımı - bower vs. npm

  

Browserify veya webpack ile tüm modüllerinizi, özellikle mobil cihazlar için mükemmel performansa sahip büyük küçültülmüş dosyalarda birleştirmek çok kolaydır. Aynı etkiyi elde etmek için önemli ölçüde daha fazla emek gerektiren Bower ile öyle değil.

     

npm ayrıca birden fazla modül sürümünü aynı anda kullanma imkanı sunar. Çok fazla uygulama gelişimi yapmadıysanız, bu başlangıçta sizi kötü bir şey olarak etkileyebilir, ancak bir kez Bağımlılık cehennemi , bir modülün birden fazla sürümüne sahip olma yeteneğinin oldukça harika bir özellik olduğunu fark edeceksiniz. Npm’nin otomatik olarak yalnızca iki sürümünü kullanmanızı sağlayan çok kullanışlı bir dedupe aracı içerdiğini unutmayın. Eğer aslında 'e sahipseniz ' e göre - eğer her ikisi de 'i kullanabilirse iki modül bir modülün aynı versiyonunu kullanabilirler. Fakat eğer yapamıyorlar , çok kullanışlı bir yönteminiz var.

( Webpack ve rollup Ağustos 2016 itibariyle Browserify'den daha iyi olarak kabul edilir.)

    
127
2017-11-16 21: 40: 48Z
  1. web paketi ve npm daha iyi olduğunu düşünüyorum.
    2016-08-30 13: 58: 52Z
  2. < sarcasm > Lütfen 'merhaba dünya' npm projesinin bile çalışması için 300'den fazla modüle ihtiyacı olduğunu unutmayın ... < /sarcasm > : O
    2016-12-11 18: 36: 31Z
  3. "Büyük küçültülmüş dosyaların" "performans, özellikle mobil cihazlar için harika" olduğuna katılıyorum. Tam tersi: Sınırlı bant genişliği talep üzerine yüklenen küçük dosyalar gerektirir.
    2017-04-09 14: 03: 52Z
  4. Çok iyi bir tavsiye değil. Çoğu npm paketi yalnızca nodejs arka ucudır. Eğer arka uçta javascript yapmıyorsanız ya da yerinde bir modül yoksa, paket sayısı ilgisizdir çünkü Bower ihtiyaçlarınızı daha iyi karşılayacaktır
    2017-04-11 17: 59: 15Z
  5. @ GerardoGrignoli: bower yola çıktı .
    2017-04-12 08: 30: 45Z

Bower, modüllerin tek bir versiyonunu korur, yalnızca sizin için doğru /en iyisini seçmenize yardımcı olmaya çalışır.

  

Javascript bağımlılık yönetimi: npm, bower vs volo ?

NPM, düğüm modülleri için daha iyidir, çünkübir modül sistemi var ve yerel olarak çalışıyorsunuz. Bower tarayıcı için iyidir, çünkü şu anda yalnızca genel kapsam vardır ve birlikte çalıştığınız sürüm konusunda çok seçici olmak istersiniz.

    
45
2017-05-23 11: 55: 01Z
  1. Sindre'nin iç içe bağımlılık hakkında konuştuğunda bahsettiğinden bahsettiğini hissediyorum.
    2014-07-19 21: 21: 01Z
  2. @ GamesBrainiac sizin doğru, sadece kendi kelimelerime koyacağımı düşündüm.
    2014-07-20 11: 01: 47Z
  3. @ Sagivf Bunlar, eğer orijinal cevabı verenler de değilseniz, kendi kelimelerinizdir NOT href = "http://stackoverflow.com/a/22101165/2317532"> burada
    2015-03-03 06: 36: 25Z
  4. @ Sagivf Burada bir cevap vermedilerse, diğerlerinin cevaplarının ** ilgili kısımlarının kopyalanmasında yanlış bir şey yoktur. Sadece beni biraz rahatsız etti, "sadece kendi sözlerime koyacağımı düşündüm" dedin. Kredi, kredinin ödemesi gereken yere gitmelidir.
    2015-03-04 10: 39: 14Z
  5. Bu cevabı neden bu kadar seçtiğinizi bilmiyorum. Bana bu cevabı gerçekten yeni bilgi /bakış açısı var.
    2015-11-30 22: 04: 44Z

Ekibim Bower’dan uzaklaştı ve npm’ye geçti, çünkü:

  • Programlı kullanım acı verdi
  • Bower'ın arayüzü değişmeye devam etti
  • URL kısayolu gibi bazı özellikler tamamen bozuldu
  • Aynı projede hem Bower hem de npm kullanmak acı vericidir
  • bower.json sürüm alanının git etiketleriyle senkronize tutulması acı vericidir
  • Kaynak kontrolü! = paket yönetimi
  • CommonJS desteği kolay değil

Daha fazla ayrıntı için, bkz. "Ekibim npm yerine npm kullanıyor Bower ".

    
33
2015-11-21 04: 04: 51Z

Bu yararlı açıklamayı http://ng-learn.org/2013/11/Bower adresinde bulabilirsiniz. -vs-npm /

  

Bir yandan npm, node.js ortamında kullanılan modülleri veya Karma, lint, minifiers ve benzeri node.js kullanılarak oluşturulan geliştirme araçlarını yüklemek için yaratıldı. npm modülleri yerel olarak bir projeye kurabilir (varsayılan olarak node_modules'da) veya genel olarak birden fazla proje tarafından kullanılmak üzere kurabilir. Büyük projelerde bağımlılıkları belirleme yolu, bağımlılıkların listesini içeren package.json adlı bir dosya oluşturmaktır. Bu liste, npm kurulumunu çalıştırdığınızda npm tarafından tanınır; ardından bunları sizin için indirip yükler.

     

Öte yandan, bower ön uç bağımlılıklarınızı yönetmek için yaratıldı. JQuery, AngularJS, alt çizgi, vb. Gibi kütüphaneler. Npm'ye benzer şekilde, bower.json adlı bir bağımlılık listesi belirleyebileceğiniz bir dosya vardır. Bu durumda ön uç bağımlılıklarınız, bunları varsayılan olarak bower_components adlı bir klasöre yükleyen bower kurulumunu çalıştırarak kurulur.

     

Görebildiğiniz gibi, benzer bir görevi yerine getirmelerine rağmen, çok farklı bir kitaplık kümesini hedef alırlar.

    
17
2014-10-10 03: 26: 45Z
  1. npm dedupe'un gelişiyle bu biraz modası geçmiş. Mattias’ın cevabına bakın.
    2015-07-04 10: 49: 58Z

node.js ile çalışan birçok kişi için, bower’ın büyük bir yararı, javascript olmayan bağımlılıkları yönetmektir. Javascript'i derleyen dillerle çalışıyorlarsa, npm bazı bağımlılıklarını yönetmek için kullanılabilir. Ancak, tüm bağımlılıkları node.js modülleri olmayacak. Javascript'i derleyenlerden bazıları, kullanıcılar kaynak kodu beklerken javascript'e bir inelegant seçeneği olarak derlenmiş halde dolaşan tuhaf bir kaynak diline özgü bir yönetime sahip olabilir.

Bir npm paketindeki her şeyin kullanıcının karşı karşıya olduğu bir javascript olması gerekmez, ancak npm kütüphane paketleri için en azından birisinin olması gerekir.

    
7
2014-10-11 21: 27: 09Z
  1. Bu npmjs blog yazısı , "Paketiniz ES6, istemci tarafı JS veya hatta HTML ve CSS de dahil olmak üzere her şeyi içerebilir. Bunlar, JavaScript'in yanında doğal olarak ortaya çıkan şeyler, bu yüzden onları buraya yerleştirin."
    2015-07-04 10: 28: 22Z
  2. içerebilir ile içermeli arasında bir fark var. Elbette her şeyi içerebilirler, ancak genel olarak, ortak JS ile bir çeşit arayüz içermesi gerekir. Sonuçta 'düğüm paket yöneticisi'. Bunlar, Javascript ile birlikte doğal olarak ortaya çıkan şeylerdir. Javascript ile ilgili olarak, doğal olarak tarafa dönmeyen , teğet olan birçok şey var.
    2015-12-09 02: 43: 01Z
kaynak yerleştirildi İşte