Vraag Wat is het verschil tussen Bower en npm?


Wat is het fundamentele verschil tussen bower en npm? Ik wil gewoon iets eenvoudigs. Ik heb een aantal van mijn collega's zien gebruiken bower en npm uitwisselbaar in hun projecten.


1611
2017-09-05 16:53


oorsprong


antwoorden:


Alle pakketbeheerders hebben veel nadelen. Je moet gewoon kiezen met wie je kunt leven.

Geschiedenis

NPM begon met het beheren van node.js-modules (daarom gaan pakketten in node_modules standaard), maar het werkt ook voor de front-end in combinatie met Browserify of WebPack.

Prieel is uitsluitend gemaakt voor de front-end en is daarmee geoptimaliseerd.

Grootte van repo

npm is veel, veel groter dan prieel, inclusief JavaScript voor algemene doeleinden (zoals country-data voor landinformatie of sorts voor het sorteren van functies die bruikbaar zijn aan de voorkant of de achterkant).

Bower heeft een veel kleiner aantal pakketten.

Behandeling van stijlen enz

Bower bevat stijlen, enz.

npm is gericht op JavaScript. Stijlen worden afzonderlijk gedownload of vereist door iets als npm-sass of sass-npm.

Afhankelijkheid afhandeling

Het grootste verschil is dat npm afhankelijkheden heeft genest (maar standaard is flat), terwijl Bower een flat-dependency-structuur vereist (legt de last van afhankelijkheidsresolutie op de gebruiker).

Een geneste afhankelijkheidsboom betekent dat uw afhankelijkheden hun eigen afhankelijkheden kunnen hebben die ze kunnen hebben, enzovoort. Dit maakt het mogelijk dat twee modules verschillende versies van dezelfde onbetrouwbaarheid vereisen en nog steeds werken. Opmerking sinds npm v3, de afhankelijkheidsboom wordt standaard plat (besparing van ruimte) en alleen nesten waar nodig, bijvoorbeeld als twee afhankelijkheden hun eigen versie van Underscore nodig hebben.

Sommige projecten gebruiken beide omdat ze Bower gebruiken voor front-endpakketten en npm voor ontwikkelaarstools zoals Yeoman, Grunt, Gulp, JSHint, CoffeeScript, etc.


Middelen


1828
2017-09-06 08:09



Dit antwoord is een aanvulling op het antwoord van Sindre Sorhus. Het grote verschil tussen npm en Bower is de manier waarop ze recursieve afhankelijkheden behandelen. Merk op dat ze samen in één project kunnen worden gebruikt.

Op de Veelgestelde vragen over npm: (link archive.org vanaf 6 september 2015)

Het is veel moeilijker om afhankelijkheidsconflicten te voorkomen zonder te nesten   afhankelijkheden. Dit is fundamenteel voor de manier waarop npm werkt en heeft   bewezen een uiterst succesvolle aanpak te zijn.

Op Prieel Startpagina:

Bower is geoptimaliseerd voor de front-end. Bower maakt gebruik van een platte afhankelijkheid   boom, waarvoor slechts één versie voor elk pakket nodig is, waardoor de pagina wordt geladen   tot een minimum.

Kortom, npm streeft naar stabiliteit. Bower streeft naar minimale resourcebelasting. Als u de afhankelijkheidsstructuur tekent, ziet u dit:

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

Zoals je ziet, installeert het enkele afhankelijkheden recursief. Afhankelijkheid A heeft drie geïnstalleerde exemplaren!

Prieel:

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

Hier zie je dat alle unieke afhankelijkheden op hetzelfde niveau liggen.

Dus waarom zou u moeite doen om npm te gebruiken?

Misschien vereist afhankelijkheid B een andere afhankelijkheidsversie dan afhankelijkheid C. npm installeert beide versies van deze afhankelijkheid zodat het toch werkt, maar Bower geeft je een conflict omdat het niet van duplicatie houdt (omdat het laden van dezelfde bron op een webpagina erg inefficiënt en kostbaar is, kan het ook ernstige fouten veroorzaken). U zult handmatig moeten kiezen welke versie u wilt installeren. Dit kan het effect hebben dat een van de afhankelijkheden zal breken, maar dat is iets dat je toch moet repareren.

Het algemene gebruik is dus Bower voor de pakketten die u op uw webpagina's wilt publiceren (bijv. runtime, waar u duplicatie voorkomt) en gebruik npm voor andere dingen, zoals testen, bouwen, optimaliseren, controleren, enz. (bijv. ontwikkelingstijd, waar duplicatie minder zorgwekkend is).

Update voor npm 3:

npm 3 doet nog steeds dingen anders in vergelijking met Bower. Het zal de afhankelijkheden globaal installeren, maar alleen voor de eerste versie die het tegenkomt. De andere versies zijn geïnstalleerd in de structuur (de bovenliggende module en vervolgens node_modules).

  • [Node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (gebruikt rootversie)
    • dep C v1.0
      • dep A v2.0 (deze versie verschilt van de rootversie, dus het zal een geneste installatie zijn)

Voor meer informatie, raad ik aan het lezen van de documenten van npm 3


338
2017-11-24 13:10



TL; DR: Het grootste verschil in dagelijks gebruik zijn geen geneste afhankelijkheden ... het is het verschil tussen modules en globalen.

Ik denk dat de vorige posters een aantal van de basisverschillen goed hebben behandeld. (gebruik van geneste afhankelijkheden van npm is inderdaad erg handig bij het beheer van grote, complexe applicaties, hoewel ik niet denk dat dit het belangrijkste onderscheid is.)

Het verbaast me echter dat niemand expliciet een van de meest fundamentele verschillen tussen Bower en npm heeft uitgelegd. Als u de bovenstaande antwoorden leest, ziet u het woord 'modules' vaak gebruikt in de context van npm. Maar het wordt terloops genoemd, alsof het misschien zelfs maar een syntaxisverschil is.

Maar dit onderscheid van modules versus globals (of modules versus 'scripts') is mogelijk het belangrijkste verschil tussen Bower en npm. De aanpak van npm om alles in modules te plaatsen, vereist dat je de manier verandert waarop je Javascript voor de browser schrijft, vrijwel zeker ten goede.

The Bower Approach: Global Resources, zoals <script> Tags

In root gaat Bower over het laden van standaard scriptbestanden. Wat deze scriptbestanden ook bevatten, Bower laadt ze. Wat in feite betekent dat Bower net zo is als het opnemen van al je scripts in gewoon oud <script>zit in de <head> van uw HTML.

Dus, dezelfde basisaanpak die u gewend bent, maar u krijgt een aantal leuke automatiseringsvoorzieningen:

  • Vroeger moest u JS-afhankelijkheden opnemen in uw projectrepo (terwijl u bezig was met ontwikkelen) of ze krijgen via CDN. Nu kun je dat extra downloadgewicht overslaan in de repo en iemand kan het snel doen bower installen hebben onmiddellijk wat ze nodig hebben, lokaal.
  • Als een afhankelijkheid van Bower dan zijn eigen afhankelijkheden in zijn specificeert bower.json, die worden ook voor u gedownload.

Maar verder, Bower verandert niets aan hoe we javascript schrijven. Niets over wat er in de bestanden zit die door Bower zijn geladen, moet helemaal worden gewijzigd. Dit betekent in het bijzonder dat de bronnen in scripts die door Bower zijn geladen (meestal, maar niet altijd) nog steeds worden gedefinieerd als globale variabelen, overal beschikbaar in de browser-uitvoeringscontext.

De npm-benadering: Common JS Modules, Explicit Dependency Injection

Alle code in Node Land (en dus alle code geladen via npm) is gestructureerd als modules (specifiek, als een implementatie van de CommonJS-module-indeling, of nu, als een ES6-module). Dus, als u NPM gebruikt voor het afhandelen van afhankelijkheden van de browser (via Browserify of iets anders dat dezelfde taak uitvoert), structureert u uw code op dezelfde manier als Node.

Slimmere mensen dan ik heb de vraag 'Waarom modules?' Aangepakt, maar hier is een capsuleoverzicht:

  • Alles in een module is effectief naamruimten, wat betekent dat het niet meer een globale variabele is, en je kunt er niet per ongeluk naar verwijzen zonder het te willen doen.
  • Alles in een module moet opzettelijk in een bepaalde context worden geïnjecteerd (meestal een andere module) om er gebruik van te maken
  • Dit betekent dat je meerdere versies van dezelfde externe afhankelijkheid kunt hebben (bijvoorbeeld, letash) in verschillende delen van je applicatie, en ze zullen niet botsen / conflicteren. (Dit gebeurt verrassend vaak, omdat uw eigen code één versie van een afhankelijkheid wil gebruiken, maar een van uw externe afhankelijkheden geeft een andere aan die conflicteert. Of u hebt twee externe afhankelijkheden die elk een andere versie willen.)
  • Omdat alle afhankelijkheden handmatig in een bepaalde module worden geïnjecteerd, is het heel gemakkelijk om erover te redeneren. Je weet voor een feit: "De enige code die ik moet overwegen bij het werken aan dit is wat ik bewust heb gekozen om hier te injecteren".
  • Omdat zelfs de inhoud van geïnjecteerde modules is ingekapseld achter de variabele waaraan u het toewijst, en alle code wordt binnen een beperkt bereik uitgevoerd, verrassingen en botsingen worden zeer onwaarschijnlijk. Het is veel, veel minder waarschijnlijk dat iets van een van uw afhankelijkheden per ongeluk een globale variabele herdefinieert zonder dat u het beseft, of dat u dit zult doen. (Het kan gebeuren, maar meestal doe je er alles aan om het te doen, met zoiets window.variable. Het enige ongeluk dat nog steeds optreedt, is toewijzen this.variable, niet wetend dat this is eigenlijk window in de huidige context.)
  • Wanneer u een afzonderlijke module wilt testen, weet u heel eenvoudig: wat anders (afhankelijkheden) beïnvloedt de code die in de module wordt uitgevoerd? En omdat u alles expliciet injecteert, kunt u gemakkelijk die afhankelijkheden bespotten.

Voor mij komt het gebruik van modules voor front-end code neer op: werken in een veel smallere context waarin gemakkelijker te redeneren en te testen is, en met meer zekerheid over wat er aan de hand is.


Het kost slechts ongeveer 30 seconden om te leren hoe u de syntaxis van de CommonJS / knooppuntmodule gebruikt. Binnen een bepaald JS-bestand, dat een module gaat worden, declareer je eerst de externe afhankelijkheden die je wilt gebruiken, zoals dit:

var React = require('react');

In het bestand / de module doe je wat je normaal zou doen, en maak je een object of een functie die je aan externe gebruikers wilt blootgeven, misschien noem je dat myModule.

Aan het einde van een bestand exporteer je alles wat je met de wereld wilt delen, zoals dit:

module.exports = myModule;

Vervolgens, om een ​​CommonJS-gebaseerde workflow in de browser te gebruiken, gebruikt u tools zoals Browserify om al die individuele modulebestanden te pakken, hun inhoud tijdens runtime in te kapselen en ze naar behoefte in te spuiten.

EN, omdat ES6-modules (die je waarschijnlijk met B5 of ES5 naar ES5 transponeert) breed worden geaccepteerd en zowel in de browser als in Node 4.0 werken, moeten we een goed overzicht van die ook.

Meer over patronen voor het werken met modules in dit kaartspel.


EDIT (feb 2017): Facebook's Garen is een zeer belangrijke potentiële vervanging / aanvulling voor npm deze dagen: snel, deterministisch, offline pakketbeheer dat voortbouwt op wat npm je biedt. Het is de moeite waard om naar een JS-project te kijken, vooral omdat het zo eenvoudig is om het in / uit te wisselen.


256
2017-07-26 03:12



2017-oktober update

Bower is eindelijk geweest verouderd. Einde verhaal.

Ouder antwoord

Van Mattias Petter Johansson, JavaScript-ontwikkelaar bij Spotify:

In bijna alle gevallen is het beter om Browserify en npm over Bower te gebruiken. Het is gewoon een betere verpakkingsoplossing voor front-end apps dan Bower. Bij Spotify gebruiken we npm om hele webmodules (html, css, js) te verpakken en het werkt erg goed.

Bower kenmerkt zichzelf als de pakketbeheerder voor het web. Het zou geweldig zijn als dit waar zou zijn - een pakketmanager die mijn leven beter heeft gemaakt als een front-end ontwikkelaar zou geweldig zijn. Het probleem is dat Bower hiervoor geen gespecialiseerde tooling biedt. Het biedt GEEN gereedschappen waarvan ik weet dat npm dat niet doet, en vooral niets dat specifiek nuttig is voor front-end ontwikkelaars. Er is gewoon geen voordeel voor een front-end ontwikkelaar om Bower via npm te gebruiken.

We moeten stoppen met prieel en consolideren rond npm. Gelukkig is dat wat is aan het gebeuren:

Module counts - bower vs. npm

Met browserify of webpack wordt het supereenvoudig om al uw modules samen te voegen tot grote geminimaliseerde bestanden, wat geweldig is voor de prestaties, vooral voor mobiele apparaten. Niet zo met Bower, dat aanzienlijk meer arbeid vereist om hetzelfde effect te krijgen.

npm biedt ook de mogelijkheid om meerdere versies van modules tegelijk te gebruiken. Als je niet veel hebt gedaan aan de ontwikkeling van apps, kan dit je in eerste instantie als een slechte zaak beschouwen, maar als je eenmaal een paar keer bent overgekomen Afhankelijkheid hel je zult je realiseren dat het hebben van de mogelijkheid om meerdere versies van een module te hebben een mooie, geweldige optie is. Merk op dat npm erg handig is dedupe tool dat zorgt er automatisch voor dat je alleen twee versies van een module gebruikt als je dat echt doet hebben naar - als twee modules beide kan gebruik dezelfde versie van een module, zij zullen. Maar als ze kan niet, je hebt een heel handige uitstraling.

(Let daar op webpack en oprollen worden algemeen beschouwd als beter dan Browserify vanaf augustus 2016.)


117
2017-07-04 10:48



Bower onderhoudt een enkele versie van modules, het probeert alleen om u te helpen de juiste / beste voor u te selecteren.

Javascript dependency management: npm vs bower vs volo?

NPM is beter voor knoopmodules omdat er een modulesysteem is en u lokaal werkt. Bower is goed voor de browser, omdat er momenteel alleen een globaal bereik is en u zeer selectief wilt zijn over de versie waarmee u werkt.


43
2017-07-19 20:59



Mijn team verhuisde van Bower en migreerde naar npm omdat:

  • Programmatisch gebruik was pijnlijk
  • De interface van Bower veranderde voortdurend
  • Sommige functies, zoals de url-steno, zijn volledig verbroken
  • Het gebruik van zowel Bower als npm in hetzelfde project is pijnlijk
  • Het bijhouden van bower.json-versieveld synchroon met git-tags is pijnlijk
  • Bronbeheer! = Pakketbeheer
  • CommonJS-ondersteuning is niet eenvoudig

Zie voor meer informatie "Waarom mijn team npm gebruikt in plaats van prieel".


31
2018-02-16 21:04



Vond deze bruikbare verklaring van http://ng-learn.org/2013/11/Bower-vs-npm/

Enerzijds is npm gemaakt om modules te installeren die worden gebruikt in een node.js-omgeving, of ontwikkeltools die zijn gebouwd met node.js zoals Karma, lint, minifiers enzovoort. npm kan modules lokaal in een project installeren (standaard in node_modules) of globaal om door meerdere projecten te worden gebruikt. In grote projecten is de manier om afhankelijkheden te specificeren het maken van een bestand met de naam package.json, dat een lijst met afhankelijkheden bevat. Die lijst wordt door npm herkend wanneer u npm install uitvoert, die u vervolgens downloadt en voor u installeert.

Aan de andere kant is bower gemaakt om uw frontend afhankelijkheden te beheren. Bibliotheken zoals jQuery, AngularJS, underscore, etc. Net als bij npm heeft het een bestand waarin u een lijst met afhankelijkheden kunt opgeven, genaamd bower.json. In dit geval worden uw frontend-afhankelijkheden geïnstalleerd door prieel-installatie uit te voeren die ze standaard installeert in een map met de naam bower_components.

Zoals u kunt zien, zijn ze weliswaar gericht op een heel andere reeks bibliotheken, hoewel ze een vergelijkbare taak uitvoeren.


14
2017-10-03 00:08



Voor veel mensen die met node.js werken, is een groot voordeel van prieel het beheren van afhankelijkheden die helemaal geen JavaScript zijn. Als ze werken met talen die compileren naar javascript, kan npm worden gebruikt om enkele van hun afhankelijkheden te beheren. echter, niet al hun afhankelijkheden zullen modules node.js zijn. Sommige van die compileren naar javascript kunnen rare brontaal-specifieke mangling hebben die het doorgeven ervan gecompileerd naar javascript tot een onelegante optie maakt wanneer gebruikers de broncode verwachten.

Niet alles in een npm-pakket moet javascript zijn dat voor de gebruiker wordt gebruikt, maar voor npm-bibliotheekpakketten, zou tenminste een deel ervan moeten zijn.


4
2017-10-11 20:42



Bower en Npm zijn pakketbeheerders voor javascript.

Prieel

Bower is alleen gemaakt voor de front-end ontwikkeling. Het maakt gebruik van flat-dependency-structuur, waarvoor slechts één versie voor elk pakket nodig is, waardoor de pagina wordt geladen. Het richt zich voornamelijk op minimale resourcebelasting. Het heeft minder bijdragers en dus is het ontwikkelingsproces traag.

Bower heeft een configuratiebestand met de naam bower.json. In dit bestand kunnen we de configuratie voor Bower onderhouden, zoals afhankelijkheden die we nodig hebben en licentiegegevens, beschrijving, naam, enzovoort. Bower is geschikt voor front-end pakketten zoals jQuery, Angular, Reaction, ember, knock-out, backbone enzovoort.

NPM

Npm wordt meestal gebruikt voor het beheer van Node.js-modules, maar het werkt ook voor de front-end. Het gebruikt een geneste afhankelijkheidsboom en een flat-dependency-structuur. Het is populair en heeft veel bijdragers. Dus de nieuwe versie komt altijd met spannende functies.

Npm heeft een configuratiebestand genaamd package.json. In dit bestand kunnen we de configuratie voor Npm onderhouden, zoals afhankelijkheden die we nodig hebben en licentiegegevens, beschrijving, naam, enzovoort. NPM biedt afhankelijkheden en DevDependencies. Afhankelijkheden zullen de front-endbestanden zoals JQuery, Angular enzovoort downloaden en onderhouden. DevDependencies zal ontwikkelingshulpmiddelen zoals Grunt, Gulp, JSHint enzovoort downloaden en onderhouden.

Dit werkt duidelijk niet zo goed aan de voorkant, omdat we jQuery nodig hebben in onze projecten. We hebben slechts één exemplaar van jQuery nodig, maar als een ander pakket jQuery vereist, zal het opnieuw een kopie van jQuery downloaden. Dit is een van de belangrijkste nadelen van NPM.

Belangrijkste opmerking: De reden dat veel projecten beide gebruiken, is dat ze Bower gebruiken voor front-endpakketten en Npm voor ontwikkelaarstools. Multiplying pakketmanager in uw project maakt uw workflow moeilijker. Npm 3 gekoppeld aan browserify of webpack is de manier om nu te gaan.


1
2018-01-07 09:26