Domanda Qual è la differenza tra Bower e npm?


Qual è la differenza fondamentale tra bower e npm? Voglio solo qualcosa di semplice e chiaro. Ho visto usare alcuni dei miei colleghi bower e npm intercambiabile nei loro progetti.


1611
2017-09-05 16:53


origine


risposte:


Tutti i gestori di pacchetti hanno molti aspetti negativi. Devi solo scegliere con chi puoi vivere.

Storia

npm ha iniziato a gestire i moduli node.js (è per questo che entrano i pacchetti node_modules di default), ma funziona anche per il front-end quando combinato con Browserify o WebPack.

pergolato è creato esclusivamente per il front-end ed è ottimizzato per questo.

Dimensione del pronti contro termine

npm è molto, molto più grande di bower, incluso JavaScript generico (come country-data per informazioni sul paese o sorts per le funzioni di smistamento utilizzabili front end o back end).

Bower ha una quantità molto minore di pacchetti.

Gestione di stili ecc

Bower include stili, ecc.

npm è incentrato su JavaScript. Gli stili possono essere scaricati separatamente o richiesti da qualcosa di simile npm-sass o sass-npm.

Gestione delle dipendenze

La più grande differenza è che npm fa le dipendenze nidificate (ma è piatta per impostazione predefinita) mentre Bower richiede una struttura di dipendenza piatta (mette l'onere della risoluzione delle dipendenze sull'utente).

Un albero di dipendenza nidificato significa che le dipendenze possono avere le proprie dipendenze che possono avere le proprie e così via. Ciò consente a due moduli di richiedere versioni diverse della stessa depenency e funzionano ancora. Nota poiché npm v3, l'albero delle dipendenze sarà piatto per impostazione predefinita (risparmiando spazio) e anniderà solo dove necessario, ad esempio se due dipendenze necessitano della propria versione di Underscore.

Alcuni progetti usano entrambi è che usano Bower per pacchetti front-end e npm per strumenti di sviluppo come Yeoman, Grunt, Gulp, JSHint, CoffeeScript, ecc.


risorse


1828
2017-09-06 08:09



Questa risposta è un'aggiunta alla risposta di Sindre Sorhus. La principale differenza tra npm e Bower è il modo in cui trattano le dipendenze ricorsive. Si noti che possono essere utilizzati insieme in un singolo progetto.

Sul Domande frequenti su npm: (link archive.org del 6 set 2015)

È molto più difficile evitare i conflitti di dipendenza senza nidificazione   dipendenze. Questo è fondamentale per il modo in cui npm funziona e ha   dimostrato di essere un approccio di grande successo.

Sopra pergolato homepage:

Bower è ottimizzato per il front-end. Bower usa una dipendenza piatta   albero, richiedendo solo una versione per ogni pacchetto, riducendo il carico della pagina   al minimo

In breve, npm punta alla stabilità. Bower punta a un carico di risorse minimo. Se estrai la struttura delle dipendenze, vedrai questo:

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

Come puoi vedere installa alcune dipendenze in modo ricorsivo. Dipendenza A ha tre istanze installate!

Bower:

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

Qui vedi che tutte le dipendenze uniche sono sullo stesso livello.

Quindi, perché preoccuparsi di usare npm?

Forse la dipendenza B richiede una versione diversa della dipendenza A rispetto alla dipendenza C. npm installa entrambe le versioni di questa dipendenza in modo che funzioni ugualmente, ma Bower ti darà una conflitto perché non ama la duplicazione (perché caricare la stessa risorsa su una pagina web è molto inefficiente e costoso, può anche causare alcuni errori gravi). Dovrai selezionare manualmente la versione che desideri installare. Ciò può avere l'effetto che una delle dipendenze si interrompe, ma è qualcosa che dovrai comunque risolvere.

Pertanto, l'uso comune è Bower per i pacchetti che desideri pubblicare sulle tue pagine web (ad es. runtime, dove si evita la duplicazione) e si usa npm per altre cose, come test, creazione, ottimizzazione, controllo, ecc. (ad es. tempo di sviluppo, dove la duplicazione è meno preoccupante).

Aggiornamento per npm 3:

npm 3 fa ancora le cose in modo diverso rispetto a Bower. Installa le dipendenze a livello globale, ma solo per la prima versione che incontra. Le altre versioni sono installate nell'albero (il modulo genitore, quindi node_modules).

  • [node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (usa la versione di root)
    • dep C v1.0
      • dep A v2.0 (questa versione è diversa dalla versione root, quindi sarà un'installazione nidificata)

Per ulteriori informazioni, suggerisco di leggere il documenti di npm 3


338
2017-11-24 13:10



TL; DR: La più grande differenza nell'uso quotidiano non è una dipendenza nidificata ... è la differenza tra moduli e globali.

Penso che i precedenti poster abbiano coperto bene alcune delle distinzioni di base. (L'uso di npm delle dipendenze nidificate è davvero molto utile nella gestione di applicazioni grandi e complesse, sebbene non ritenga che sia la distinzione più importante.)

Sono sorpreso, tuttavia, che nessuno abbia esplicitamente spiegato una delle distinzioni più fondamentali tra Bower e npm. Se leggi le risposte sopra, vedrai la parola "moduli" usata spesso nel contesto di npm. Ma è citato casualmente, come se potesse anche solo essere una differenza di sintassi.

Ma questa distinzione di moduli contro globali (o moduli vs. "script") è probabilmente la differenza più importante tra Bower e npm. L'approccio npm di mettere tutto nei moduli richiede di cambiare il modo in cui si scrive Javascript per il browser, quasi certamente per il meglio.

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

Alla radice, Bower riguarda il caricamento di file di script semplici. Qualunque sia il contenuto di questi file di script, Bower li caricherà. Il che significa sostanzialmente che Bower è come includere tutti i tuoi script in plain-old <script>è nel <head> del tuo HTML.

Quindi, lo stesso approccio di base a cui sei abituato, ma ottieni alcune buone comodità di automazione:

  • Avevi bisogno di includere dipendenze JS nel tuo repository di progetto (durante lo sviluppo), o ottenerle tramite CDN. Ora puoi saltare il peso del download aggiuntivo nel repository e qualcuno può fare un veloce bower installe immediatamente hanno ciò di cui hanno bisogno, localmente.
  • Se una dipendenza di Bower specifica le proprie dipendenze nella sua bower.json, anche quelli verranno scaricati per te.

Ma oltre a questo, Bower non cambia il modo in cui scriviamo javascript. Niente su ciò che entra nei file caricati da Bower deve cambiare. In particolare, ciò significa che le risorse fornite negli script caricati da Bower saranno (di solito, ma non sempre) ancora definite come variabili globali, disponibile ovunque nel contesto di esecuzione del browser.

Approccio npm: moduli JS comuni, iniezione esplicita delle dipendenze

Tutto il codice in terra dei nodi (e quindi tutto il codice caricato via npm) è strutturato come moduli (in particolare, come implementazione del Formato del modulo CommonJS, o ora, come un modulo ES6). Quindi, se usi NPM per gestire le dipendenze sul browser (tramite Browserify o qualcos'altro che fa lo stesso lavoro), strutturerai il tuo codice nello stesso modo in cui lo fa Node.

Le persone più intelligenti di me hanno affrontato la questione "Perché i moduli?", Ma ecco un riassunto delle capsule:

  • Qualsiasi cosa all'interno di un modulo è efficace namespace, nel senso che non è più una variabile globale e non puoi accedervi accidentalmente senza volerlo.
  • Qualunque cosa all'interno di un modulo deve essere intenzionalmente iniettata in un particolare contesto (di solito un altro modulo) per farne uso
  • Ciò significa che puoi avere più versioni della stessa dipendenza esterna (lodash, diciamo) in varie parti della tua applicazione e che non si scontreranno / entreranno in conflitto. (Questo accade sorprendentemente spesso, perché il tuo codice vuole usare una versione di una dipendenza, ma una delle tue dipendenze esterne ne specifica un'altra che va in conflitto, oppure hai due dipendenze esterne che ognuna desidera una versione diversa.)
  • Poiché tutte le dipendenze vengono inserite manualmente in un particolare modulo, è molto facile ragionare su di esse. Sai per certo "L'unico codice che devo considerare quando lavoro su questo è quello che ho intenzionalmente scelto di iniettare qui".
  • Perché anche il contenuto dei moduli iniettati è incapsulato dietro la variabile a cui viene assegnato e tutto il codice viene eseguito all'interno di un ambito limitato, sorprese e collisioni diventano molto improbabili. È molto, molto meno probabile che qualcosa da una delle tue dipendenze ridefinirà accidentalmente una variabile globale senza che tu te ne accorga o che lo farai. (E ' può capita, ma di solito devi fare di tutto per farlo, con qualcosa di simile window.variable. L'unico incidente che tende ancora a verificarsi è l'assegnazione this.variable, non rendendolo conto this è effettivamente window nel contesto attuale.)
  • Quando vuoi testare un singolo modulo, sei in grado di sapere molto facilmente: esattamente quale altro (dipendenze) sta influenzando il codice che viene eseguito all'interno del modulo? E, poiché stai iniettando esplicitamente tutto, puoi facilmente prendere in giro queste dipendenze.

Per me, l'uso di moduli per il codice di front-end si riduce a: lavorare in un contesto molto più ristretto che è più facile ragionare e testare e avere maggiore certezza su cosa sta succedendo.


Ci vogliono solo circa 30 secondi per imparare come usare la sintassi del modulo CommonJS / Node. All'interno di un determinato file JS, che sarà un modulo, dichiarare per prima cosa tutte le dipendenze esterne che si desidera utilizzare, come questa:

var React = require('react');

All'interno del file / modulo, fai qualunque cosa tu voglia normalmente, e crea qualche oggetto o funzione che vorresti esporre agli utenti esterni, chiamandolo forse myModule.

Alla fine di un file, esporti ciò che vuoi condividere con il mondo, in questo modo:

module.exports = myModule;

Quindi, per utilizzare un flusso di lavoro basato su CommonJS nel browser, userete strumenti come Browserify per catturare tutti i singoli file di modulo, incapsulare i loro contenuti in fase di runtime e iniettarli l'uno nell'altro secondo necessità.

E, dal momento che i moduli ES6 (che probabilmente traspari in ES5 con Babel o simili) stanno ottenendo ampia accettazione e funzionano sia nel browser che nel Nodo 4.0, dovremmo menzionare un buona panoramica di quelli pure.

Ulteriori informazioni sui modelli per lavorare con i moduli in questo mazzo.


EDIT (febbraio 2017): Facebook Filato è un rimpiazzo / supplemento potenziale molto importante per npm in questi giorni: gestione dei pacchetti offline, deterministica, offline che si basa su ciò che ti dà NPM. Vale la pena dare un'occhiata a qualsiasi progetto JS, in particolare perché è così facile da scambiare dentro / fuori.


256
2017-07-26 03:12



Aggiornamento 2017-ottobre

Bower è stato finalmente deprecato. Fine della storia.

Risposta precedente

Da Mattias Petter Johansson, sviluppatore JavaScript di Spotify:

In quasi tutti i casi, è più appropriato utilizzare Browserify e npm su Bower. È semplicemente una soluzione di packaging migliore per le app di front-end rispetto a Bower. A Spotify usiamo npm per impacchettare interi moduli web (html, css, js) e funziona molto bene.

Bower si autodefinisce come gestore di pacchetti per il web. Sarebbe fantastico se fosse vero - un gestore di pacchetti che mi ha reso la vita migliore come sviluppatore front-end sarebbe fantastico. Il problema è che Bower non offre strumenti specifici per lo scopo. Non offre strumenti che io sappia che npm no, e specialmente nessuno che sia specificamente utile per gli sviluppatori front-end. Non c'è semplicemente alcun vantaggio per uno sviluppatore front-end di utilizzare Bower su npm.

Dovremmo smettere di usare bower e consolidarci attorno a npm. Per fortuna, questo è quello sta succedendo:

Module counts - bower vs. npm

Con browserify o webpack, diventa estremamente facile concatenare tutti i tuoi moduli in file minifigurati, il che è fantastico per le prestazioni, specialmente per i dispositivi mobili. Non così con Bower, che richiederà molto più lavoro per ottenere lo stesso effetto.

npm offre anche la possibilità di utilizzare più versioni di moduli contemporaneamente. Se non hai fatto molto sviluppo di applicazioni, questo potrebbe inizialmente sembrarti una brutta cosa, ma una volta che hai passato alcuni periodi di Infernale dipendenza ti renderai conto che avere la possibilità di avere più versioni di un modulo è una caratteristica davvero dannatamente bella. Si noti che npm include molto utile strumento di deduplicazione questo automaticamente fa in modo che tu usi solo due versioni di un modulo, se davvero avere a - se due moduli entrambi può usano la stessa versione di un modulo, lo faranno. Ma se loro non si può, hai una mano molto utile.

(Nota che Webpack e rollup sono ampiamente considerati migliori di Browserify a partire da agosto 2016.)


117
2017-07-04 10:48



Bower mantiene una singola versione di moduli, cerca solo di aiutarti a selezionare quello corretto / migliore per te.

Gestione delle dipendenze Javascript: npm vs bower vs volo?

NPM è migliore per i moduli di nodo perché c'è un sistema di moduli e stai lavorando localmente. Bower fa bene al browser perché attualmente c'è solo l'ambito globale e si vuole essere molto selettivi sulla versione con cui si lavora.


43
2017-07-19 20:59



La mia squadra si è trasferita da Bower e ha migrato su npm perché:

  • L'uso programmatico era doloroso
  • L'interfaccia di Bower continuava a cambiare
  • Alcune funzionalità, come l'url stenografia, sono completamente infranti
  • Usare sia Bower che npm nello stesso progetto è doloroso
  • Mantenere il campo della versione di bower.json in sincronia con i tag git è doloroso
  • Controllo del codice sorgente! = Gestione dei pacchetti
  • Il supporto di CommonJS non è semplice

Per maggiori dettagli, vedi "Perché la mia squadra usa npm invece di bower".


31
2018-02-16 21:04



Ho trovato questa utile spiegazione da http://ng-learn.org/2013/11/Bower-vs-npm/

Da un lato npm è stato creato per installare i moduli utilizzati in un ambiente node.js, o strumenti di sviluppo creati usando node.js come Karma, Lint, minifiers e così via. npm può installare moduli localmente in un progetto (per impostazione predefinita in node_modules) o globalmente per essere utilizzati da più progetti. Nei progetti di grandi dimensioni, il modo per specificare le dipendenze consiste nel creare un file chiamato package.json che contiene un elenco di dipendenze. Tale elenco viene riconosciuto da npm quando si esegue l'installazione di npm, che quindi viene scaricato e installato per l'utente.

D'altra parte è stato creato bower per gestire le dipendenze frontend. Librerie come jQuery, AngularJS, underscore, ecc. Simile a npm ha un file in cui è possibile specificare un elenco di dipendenze chiamato bower.json. In questo caso, le dipendenze frontend vengono installate eseguendo bower install che, per impostazione predefinita, le installa in una cartella denominata bower_components.

Come puoi vedere, sebbene eseguano un'attività simile, sono mirati a un insieme di librerie molto diverso.


14
2017-10-03 00:08