Bower ve npm arasındaki fark nedir?

Arasındaki temel fark nedir bowerve npm? Sadece sade ve basit bir şey isteyin. Ben arkadaşlarım kullanım bazılarını gördüm bowerve npmonların projelerinde birbirinin.

Tüm paket yöneticilerinin birçok dezavantajı vardır. Sadece birlikte yaşayabileceğin birini seçmelisin.

Tarih

npm , node.js modüllerini yönetmeye başladı (bu yüzden paketler node_modulesvarsayılan olarak devreye girer ), ancak Browserify veya webpack ile birleştirildiğinde de ön uç için çalışır .

Bower yalnızca ön uç için yaratılmıştır ve bunu göz önünde bulundurarak optimize edilmiştir.

Repo büyüklüğü

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

Bower çok daha az miktarda pakete sahiptir.

Tarzların işlenmesi vb.

Bower stilleri içerir vb.

npm JavaScript üzerine odaklanmıştır. Stiller ya ayrı indirilen veya benzeri bir şey tarafından gerekli npm-sassya sass-npm.

Bağımlılık yönetimi

En büyük fark, npm'in iç içe 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 çözünürlüğü yükünü kullanıcıya yükler) .

Yuvalanmış bir bağımlılık ağacı, bağımlılıklarınızın kendi bağımlılıklarına sahip olabileceği anlamına gelir. Bu, iki modülün aynı bağımlılığın farklı sürümlerini gerektirmesini ve yine de çalışmasını sağlar. Npm v3'ten bu yana, bağımlılık ağacının varsayılan olarak düz (yer tasarrufu) ve yalnızca gerektiğinde, örneğin iki bağımlılığın kendi Underscore sürümüne ihtiyacı olması durumunda yuvalanacağını unutmayın.

Bazı projeler her ikisini de kullanırlar, Yeoman, Grunt, Gulp, JSHint, CoffeeScript vb.

kaynaklar

• İç İçe Bağımlılıklar - node_modules'ün neden olduğu gibi çalıştığına dair bilgi

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 yöntemidir. Bunların tek bir projede birlikte kullanılabileceğini unutmayın.

Açık npm SSS : (2015 Eylül 6'dan archive.org bağlantı)

Yuva bağımlılıkları olmadan bağımlılık çatışmalarından kaçınmak çok daha zordur. Bu, npm'nin çalışma şekli için temeldir ve son derece başarılı bir yaklaşım olduğunu kanıtlamıştır.

On Bower ana:

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

Kısacası, npm istikrarı hedefler. Bower, minimum kaynak yükü hedefliyor. Bağımlılık yapısını çizerseniz, bunu 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ı özyineli olarak kurar. Bağımlılık A'nın üç kurulu örneği vardır!

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.

Peki, neden npm kullanmaya zahmet ediyorsunuz?

Belki de bağımlılık B, bağımlılık C'den farklı bir bağımlılık sürümü gerektirir. Npm, bu bağımlılığın her iki sürümünü de yükler, böylece yine de çalışır, ancak Bower, çoğaltmayı sevmediği için size bir çakışma verecektir (çünkü bir web sayfasına aynı kaynağı yüklemek çok verimsiz ve maliyetli, ayrıca bazı ciddi hatalar verebilir). Yüklemek istediğiniz sürümü manuel olarak seçmeniz gerekecektir. Bu, bağımlılıklardan birinin kırılacağı etkisine sahip 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ğaltmayı önlediğiniz çalışma zamanı ) ve test, oluşturma, optimizasyon, kontrol vb. Gibi diğer şeyler için npm'yi (ör. Geliştirme süresi) çoğaltmanın daha az endişe ettiği durumlarda).

Npm 3 için güncelleme:

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

• [Node_modules]
  • dep A v1.0
  • dep B v1.0
    • dep A v1.0 (root 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 iç içe kurulum olacaktır)

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

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

Önceki posterlerin bazı temel ayrımları iyi kapsadığını düşünüyorum. (npm'in iç içe bağımlılıkları kullanması, büyük, karmaşık uygulamaların yönetiminde gerçekten çok yararlıdır, ancak bunun en önemli ayrım olduğunu düşünmüyorum.)

Bununla birlikte, hiç kimsenin Bower ve npm arasındaki en temel ayrımlardan birini açık bir şekilde açıklamamasına şaşırdım. Yukarıdaki cevapları okursanız, npm bağlamında sıklıkla kullanılan 'modüller' kelimesini görürsünüz. Ancak, sözdizimsel bir fark bile olsa, raslantıdan bahsedilir.

Ancak modüllerin küresellere (veya modüllerin 'komut dosyalarına karşı) bu ayrımı muhtemelen Bower ve npm arasındaki en önemli farktır. Her şeyi modüllere yerleştirme npm yaklaşımı, tarayıcı için Javascript yazma şeklinizi değiştirmenizi gerektirir, neredeyse kesinlikle daha iyisi için.

Bower Yaklaşımı: <script>Etiketler gibi Global Kaynaklar

Kökte, Bower düz eski komut dosyalarını yüklemekle ilgilidir. Bu komut dosyaları ne olursa olsun, Bower bunları yükler. Temelde hangi Bower sadece düz eski tüm komut dosyalarını dahil gibi olduğunu araçlarının <script>içinde 's <head>HTML'nizin.

Yani, alıştığınız aynı temel yaklaşım, ancak bazı güzel otomasyon kolaylıkları elde edersiniz:

• Önceden proje bağımlılığınıza JS bağımlılıkları eklemeniz (geliştirirken) ya da bunları CDN yoluyla almanız gerekiyordu. Şimdi, bu ekstra indirme ağırlığını depoda atlayabilirsiniz ve birileri bower installyerel olarak hızlı ve anında ihtiyaç duydukları şeye sahip olabilir.
• Eğer bir Bower bağımlılığı kendi bağımlılıklarını bower.jsonbelirtiyorsa, bunlar sizin için de indirilecektir.

Ancak bunun ötesinde, Bower javascript yazma şeklimizi değiştirmez . Bower tarafından yüklenen dosyaların içine ne gireceği hakkında hiçbir şey değişmez. Özellikle, 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ında herhangi bir yerden kullanılabilen 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 arazisindeki tüm kodlar (ve dolayısıyla npm yoluyla yüklenen tüm kodlar) modüller olarak yapılandırılır (özellikle CommonJS modülü formatının bir uygulaması olarak veya şimdi bir ES6 modülü olarak). Dolayısıyla, tarayıcı tarafı bağımlılıklarını (Browserify veya aynı işi yapan başka bir şey aracılığıyla) işlemek için NPM kullanıyorsanız, kodunuzu Düğüm ile aynı şekilde yapılandırırsınız.

Benden daha akıllı insanlar 'Neden modüller?' Sorusunu ele aldı, ama işte bir kapsül özeti:

• Bir modül içinde herhangi bir şey etkili bir edilir isimalanlı Bundan daha global bir değişken değil yani, ve yanlışlıkla amacı gütmeden bunu başvuramaz.
• Bir modülün içindeki her şey, onu kullanmak için kasıtlı olarak belirli bir bağlama (genellikle başka bir modül) enjekte edilmelidir.
• Bu, uygulamanızın çeşitli bölümlerinde aynı harici bağımlılığın (diyelim ki diyelim) birden çok sürümüne sahip olabileceğiniz anlamına gelir ve çarpışma / çakışma olmaz. (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 bir diğerini belirtir. Ya da her biri farklı bir sürüm isteyen iki harici bağımlılığınız vardır.)
• Tüm bağımlılıklar manuel olarak belirli bir modüle enjekte edildiğinden, bunlarla ilgili akıl yürütmek çok kolaydır. Bir gerçeği biliyorsunuz: "Bu konuda çalışırken dikkate almam gereken tek kod, kasıtlı olarak buraya enjekte etmek için seçtiğim şeydir" .
• Enjekte edilen modüllerin içeriği bile, atadığınız değişkenin arkasında kapsüllendiğinden ve tüm kod sınırlı bir kapsamda yürütüldüğünden, sürprizler ve çarpışmalar çok imkansız hale gelir. Bağımlılıklarınızdan birindeki bir şeyin farkına varmadan bir global değişkeni yanlışlıkla yeniden tanımlaması veya bunu yapmanız çok daha az olasıdır. (Olabilir , ancak genellikle böyle bir şeyle bunu yapmak için kendi yolunuzdan çıkmanız gerekir window.variable. Hala gerçekleşme eğilimi gösteren tek kaza , aslında mevcut bağlamda this.variableolduğunu fark etmek değil , atamaktır .)thiswindow
• Tek bir modülü test etmek istediğinizde çok kolay bir şekilde anlayabilirsiniz: modülün içinde çalışan kodu tam olarak başka ne (bağımlılıklar) etkiliyor? Ve, her şeyi açıkça enjekte ettiğiniz için, bu bağımlılıkları kolayca alay edebilirsiniz.

Bana göre, ön uç kodu için modüllerin kullanımı şununla ilgilidir: akıl yürütmesi ve sınaması daha kolay olan daha dar bir bağlamda çalışmak ve neler olup bittiğinden daha fazla kesinliğe sahip olmak.

CommonJS / Node modülü sözdiziminin nasıl kullanılacağını öğrenmek yalnızca 30 saniye sürer. Bir modül olacak belirli bir JS dosyasının içinde, önce kullanmak istediğiniz herhangi bir dış bağımlılığı şöyle bildirirsiniz:

var React = require('react');

Dosya / modül içinde, normalde ne yaparsanız yapın ve dışarıdaki kullanıcılara göstermek isteyeceğiniz bir nesne veya işlev yaratabilirsiniz myModule.

Bir dosyanın sonunda, dünyayla paylaşmak istediğiniz her şeyi şu şekilde dışa aktarırsınız:

module.exports = myModule;

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

VE, ES6 modülleri (Babel veya benzeri ile ES5'e aktaracağınız) geniş bir kabul gördüğü ve hem tarayıcıda hem de Düğüm 4.0'da çalıştığı için , bunlara da iyi bir genel bakıştan bahsetmeliyiz .

Bu destedeki modüllerle çalışma desenleri hakkında daha fazla bilgi .

EDIT (Şub 2017): Facebook'un İpliği , bugünlerde npm için çok önemli bir potansiyel değiştirme / tamamlayıcıdır: npm'in size sunduklarını temel alan hızlı, deterministik, çevrimdışı paket yönetimi. Herhangi bir JS projesi için bir göz atmaya değer, özellikle de içeri / dışarı takas etmek çok kolay.

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

İplik hala aktifken , Yarn'ın bazı temel özelliklerini benimsediğinde, ivme çoğu npm'ye geri döndü.

2017-Ekim güncellemesi

Bower sonunda reddedildi . Hikayenin sonu.

Eski cevap

Spotify'daki JavaScript geliştiricisi Mattias Petter Johansson'dan :

Neredeyse tüm durumlarda, Bower üzerinden Browserify ve npm kullanmak daha uygundur. Ö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, kendisini web için paket yöneticisi olarak markalamaktadır. Bu doğru olsaydı harika olurdu - bir ön uç geliştirici olarak hayatımı daha iyi hale getiren bir paket yöneticisi harika olurdu. Sorun şu ki, Bower bu amaca yönelik özel bir takım sunmuyor. Bu npm'in bilmediğini HİÇBİR takım sunmuyor ve özellikle ön uç geliştiriciler için özellikle yararlı olan hiçbiri yok. Bir ön uç geliştiricinin Bower'ı npm üzerinden kullanmasının hiçbir faydası yoktur.

Bower kullanmayı bırakmalı ve npm civarında sağlamlaşmalıyız. Neyse ki, bu da ne oluyor :

Browserify veya webpack ile, tüm modüllerinizi büyük, küçültülmüş dosyalara birleştirmek çok kolay hale gelir, bu da özellikle mobil cihazlar için performans için harika. Aynı etkiyi elde etmek için önemli ölçüde daha fazla emek gerektiren Bower ile öyle değil.

npm ayrıca, modüllerin birden fazla sürümünü aynı anda kullanma olanağı sunar. Çok fazla uygulama geliştirme yapmadıysanız, bu başlangıçta sizi kötü bir şey olarak etkileyebilir, ancak birkaç Bağımlılık cehenneminden geçtikten sonra , bir modülün birden fazla sürümüne sahip olmanın oldukça darn olduğunu fark edeceksiniz. harika özellik. Npm bir çok kullanışlı içerdiğini Not tekilleştirme aracı otomatik olarak aslında durumunda yalnızca bir modülün iki versiyonu kullandığınızdan emin kılan sahip iki modül hem eğer - için olabilir , öldürecekler bir modülün aynı sürümünü kullanın. Ama yapamazlarsa , çok kullanışlı olursunuz.

(Bu Not WebPack ve toplaması yaygın Ağustos 2016 tarihi itibariyle daha iyi Browserify daha olduğu kabul edilmektedir)

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

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

NPM düğüm modülleri için daha iyidir çünkü bir modül sistemi vardır ve yerel olarak çalışıyorsunuzdur. Bower tarayıcı için iyi çünkü şu anda sadece küresel kapsam var ve birlikte çalıştığınız sürüm hakkında çok seçici olmak istiyorsunuz.

Ekibim Bower'dan uzaklaştı ve npm'ye taşındı çünkü:

• Programlı kullanım acı vericiydi
• Bower'ın arayüzü değişmeye devam etti
• URL kısayolu gibi bazı özellikler tamamen bozuk
• Bower ve npm'yi aynı projede kullanmak acı vericidir
• Bower.json sürüm alanını git etiketleriyle senkronize tutmak acı vericidir
• Kaynak kontrolü! = Paket yönetimi
• CommonJS desteği basit değildir

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

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

Bir yandan npm, bir node.js ortamında kullanılan modülleri veya Karma, lif, küçültücüler ve benzeri gibi node.js kullanılarak oluşturulan geliştirme araçlarını yüklemek için oluşturuldu. npm, bir projeye yerel olarak (varsayılan olarak node_modules) veya birden çok proje tarafından kullanılmak üzere modüller yükleyebilir. Büyük projelerde bağımlılıkları belirtmenin 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 ve daha sonra bunları sizin için indirir ve yükler.

Öte yandan, ön uç bağımlılıklarınızı yönetmek için bower oluşturuldu. JQuery, AngularJS, alt çizgi, vb. Gibi kütüphaneler. Npm'ye benzer şekilde, bower.json adlı bağımlılıkların bir listesini belirtebileceğiniz bir dosyaya sahiptir. Bu durumda, ön uç bağımlılıklarınız varsayılan olarak onları bower_components adlı bir klasöre yükleyen bower install çalıştırılarak yüklenir.

Gördüğünüz gibi, benzer bir görevi yerine getirmelerine rağmen, çok farklı kütüphanelere yönlendirilirler.

Node.js ile çalışan birçok insan için, bower'ın en büyük yararı, hiç javascript olmayan bağımlılıkları yönetmektir. Javascript için derlenen dillerle çalışıyorlarsa, npm bağımlılıklarının bazılarını yönetmek için kullanılabilir. ancak, tüm bağımlılıkları node.js modülleri olmayacaktır. Javascript derleme bazıları, kaynak kod beklerken javascript derlenmemiş bir seçenek derlenmiş etrafında onları çevreleyen yapar tuhaf kaynak diline özgü mangling olabilir.

Bir npm paketindeki her şeyin kullanıcıya dönük bir javascript olması gerekmez, ancak npm kütüphane paketleri için en azından bir kısmı olmalıdır.