Питання Яка різниця між Bower і npm?


Яка принципова різниця між bower і npm? Просто хочеш щось просте і просто. Я бачив, як деякі мої колеги користуються bower і npm взаємозамінно у своїх проектах.


1612
2017-09-05 16:53


походження


Відповідний відповідь stackoverflow.com/a/21199026/1310070 - sachinjain024
можливий дублікат Управління залежності Javascript: npm vs bower vs volo? - anotherdave
Відповідь на це питання здається застарілою. Чи може хтось сказати нам, що робити в 2016 році, якщо ми використовуємо npm 3, які підтримують рівну залежність? У чому полягає різниця між npm3 і bower і яка найкраща практика зараз? - amdev
Нижня лінія, @ amdev: bower тепер застаріла. npm (або Пряжа, яка є лише невеликою різницею), де вона знаходиться. Я не знаю про будь-які життєздатні альтернативи. - XML


Відповіді:


Всі менеджери пакетів мають багато недоліків. Вам просто потрібно вибрати, з яким можна жити.

Історія

нмм розпочав керувати модулями node.js (саме тому пакунки входять в node_modules за замовчуванням), але він також працює для зовнішнього інтерфейсу, коли його поєднуються Перевіряти або WebPack.

Боуер створений виключно для інтерфейсу і оптимізований з урахуванням цього.

Розмір репо

npm набагато, набагато більший, ніж bower, в тому числі загальнооб'ємний JavaScript (наприклад, country-data для інформації про країну або sorts для сортування функцій, які можна використовувати на передньому або задньому кінці).

Bower має набагато менше пакетів.

Обробка стилів тощо

Bower включає в себе стилі і т.д.

npm орієнтовано на JavaScript. Стилі завантажуються окремо або вимагають щось на зразок npm-sass або sass-npm.

Залежність обробки

Найбільша різниця полягає в тому, що npm містить вкладені залежностей (але за замовчуванням є плоскими), тоді як Bower вимагає плоского дерева залежностей (ставить тягар розподілу залежностей від користувача).

Вкладений дерево залежностей означає, що ваші залежності можуть мати власні залежностi, які можуть мати власні властивості тощо. Це дозволяє двом модулям вимагати різні варіанти однієї і тієї ж схеми і все-таки працювати. Зверніть увагу, що з npm v3 дерево залежностей буде за замовчуванням (заощаджуючи простір) і лише гніздеться там, де це потрібно, наприклад, якщо для двох залежностей потрібна власна версія підкреслення.

Деякі проекти використовують обидва варіанти, що вони використовують Bower для зовнішніх пакетів і npm для інструментів розробника, таких як Yeoman, Grunt, Gulp, JSHint, CoffeeScript та ін.


Ресурси


1828
2017-09-06 08:09



Чому не вкладене дерево залежностей робить це добре на передній частині? - Lars Nyström
Чи може пристрій інтерфейсу npm бути також рівним деревом залежностей? Я стикаюсь з "чому нам потрібні два менеджера пакетів?" дилема. - Steven Vachon
Що ви маєте на увазі за допомогою "плоского дерева залежностей"? Що плоске дерево - список? Тоді це не дерево. - mvmn
Фактично, шлях також є деревом. Це лише особливий випадок. З WikiPedia: "У математиці, а точніше в теорії графів, дерево є неорієнтованим графіком, в якому будь-які дві вершини пов'язані рівно на одному шляху". - Jørgen Fogh
npm 3 тепер підтримує дерево залежностей. - vasa


Ця відповідь є доповненням до відповіді Сіндре Соргус. Основна відмінність між npm та Bower - це спосіб лікування рекурсивних залежностей. Зауважте, що їх можна використовувати разом у одному проекті.

На нмм FAQ: (link archive.org від 6 вересня 2015 р.)

Набагато складніше уникнути конфліктів у відносинах між собою, без гніздування   залежності. Це є основою для того, як працює npm, і має   що виявився надзвичайно успішним підходом.

На Боуер домашня сторінка:

Bower оптимізовано для переднього краю. Bower використовує рівну залежність   дерево, що вимагає лише однієї версії для кожного пакунка, зменшуючи завантаження сторінки   до мінімуму.

Одним словом, npm націлені на стабільність. Bower прагне до мінімального завантаження ресурсів. Якщо ви витягнете структуру залежностей, ви побачите це:

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

Як видно, він встановлює деякі залежності рекурсивно. Залежність А має три встановлені екземпляри!

Боуер:

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

Тут ви бачите, що всі унікальні залежностей знаходяться на одному рівні.

Отже, навіщо використовувати npm?

Можливо, для залежності B потрібна інша версія залежності A, ніж залежність C. npm встановлює обидві версії цієї залежності так що вона буде працювати в будь-якому випадку, але Bower дасть вам конфлікт тому що він не любить дублювання (оскільки завантаження одного і того ж ресурсу на веб-сторінку дуже неефективно та дорого, а також може призвести до серйозних помилок). Вам доведеться вручну вибрати версію, яку ви хочете встановити. Це може призвести до того, що одна з залежностей буде порушена, але це те, що потрібно буде виправити в будь-якому випадку.

Таким чином, загальним використанням є Bower для пакетів, які ви хочете опублікувати на своїх веб-сторінках (наприклад, runtime, де ви уникаєте дублювання), і використовуйте npm для інших матеріалів, наприклад, тестування, створення, оптимізації, перевірки тощо (наприклад, час розробки, де дублювання не викликає занепокоєння).

Оновлення для npm 3:

npm 3 все ще робить речі по-різному в порівнянні з Bower. Вона буде встановлювати залежності в глобальному масштабі, але тільки для першої версії він стикається. Інші версії встановлені в дереві (батьківський модуль, потім node_modules).

  • [node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (використовує кореневу версію)
    • dep C v1.0
      • dep A v2.0 (ця версія відрізняється від кореневої версії, тому вона буде вкладеною установкою)

Для отримання додаткової інформації пропоную прочитати документи npm 3


338
2017-11-24 13:10



Тепер це майже кліше, коли "розробка програмного забезпечення - це все, що стосується компромісів". Це хороший приклад. Треба вибрати або більша стабільність з npm  або мінімальний ресурс навантаження з bower. - jfmercer
@Shrek Я неявно заявляю, що ви дійсно можете використовувати обидва. Вони мають різні цілі, як я зазначаю в останньому абзаці. Це не компроміс на моїх очах. - Justus Romijn
Ага, я бачу, що я неправильно зрозумів вас. Або я не читав досить ретельно. Дякую за роз'яснення. :-) Добре, що обидва можна використовувати без компромісу. - jfmercer
@AlexAngas Я додав оновлення для npm3. Вона як і раніше має деякі істотні відмінності у порівнянні з Bower. npm, ймовірно, завжди підтримуватиме декілька версій залежностей, тоді як Bower не має. - Justus Romijn
npm 3, наближаючись до альтанки;) - ni3


TL; DR: Найбільша різниця в повсякденному використанні не вкладені залежностей ... це різниця між модулями та globals.

Я думаю, що попередні плакати добре покрили деякі основні відмінності. (Використання npm вкладеної залежностей насправді дуже корисно для управління великими, складними додатками, хоча я не вважаю, що це найважливіша відмінність).

Я здивований тим, що ніхто не чітко пояснив одну з найбільш фундаментальних відмінностей між Bower і npm. Якщо ви прочитаєте відповіді вище, ви побачите слово "модулі", яке часто використовується в контексті npm. Але це згадується випадково, як би це може бути просто синтаксичною різницею.

Але це відмінність модулі проти globals (або модулі або "скрипти"), можливо, найважливіша відмінність між Bower і npm. Підхід npm до введення всього в модулі вимагає, щоб ви змінили спосіб написання Javascript для браузера, майже напевно на краще.

Підхід Bower: глобальні ресурси, як <script> Теги

У корінні, Bower це завантаження старих файлів сценаріїв. Незалежно від цих файлів сценарію, Bower буде завантажувати їх. Що в основному означає, що Bower точно так само, як включити всі ваші скрипти в простий старий <script>в Росії <head> вашого HTML-коду.

Отже, той же основний підхід, до якого ви звикли, але ви отримуєте якісні зручності для автоматизації:

  • Вам доводилося включати JS-залежності в репо репозиторію (під час розробки) або отримати їх через CDN. Тепер ви можете пропустити цю додаткову вагу завантаження в репо, і хтось може зробити це швидко bower installі миттєво отримали те, що їм потрібно, локально.
  • Якщо залежність Bower визначає власні залежностi в її bower.json, ці будуть завантажені і для вас.

Але поза цим Bower не змінює способи написання JavaScript. Нічого про те, що йде всередині файлів, завантажених Bower, потрібно взагалі змінити. Зокрема, це означає, що ресурси, надані в сценаріях, завантажених Bower буде (зазвичай, але не завжди), як і раніше, визначаються як глобальні змінні, доступний з будь-якої точки контексту виконання браузера.

Підхід npm: загальні JS модулі, явні ін'єкції залежностей

Весь код на Землі вузла (і, отже, весь код, завантажений через npm) структурований як модулі (зокрема, як реалізація Формат модуля CommonJS, або зараз як модуль ES6). Отже, якщо ви використовуєте NPM для обробки залежностей браузера (через Browserify або щось інше, що виконує ту саму роботу), ви структуруєте свій код так само, як це робить вузол.

Спритніші люди, ніж я вирішив питання "Чому модулі?", Але ось короткий опис капсули:

  • Що завгодно всередині модуля ефективно назви, що означає, що це більше не глобальна змінна, і ви не можете випадково вказувати на неї без наміру.
  • Все, що знаходиться всередині модуля, має бути навмисне введено в певний контекст (як правило, інший модуль), щоб його використовувати
  • Це означає, що у різних частинах вашої програми можуть бути декілька версій однієї і тієї ж зовнішньої залежності (логос, скажімо так), і вони не зіткнуться / не конфліктують. (Це відбувається на диво часто, оскільки ваш власний код хоче використовувати одну версію заледеніння, однак одна із ваших зовнішніх залежностей вказує іншу, яка конфліктує, або у вас є дві зовнішні залежностей, кожен з яких хоче іншу версію).
  • Оскільки всі залежності вводяться вручну в певний модуль, про них дуже легко обміркувати. Ви знаєте за фактом: "Єдиний код, який я повинен розглянути під час роботи над цим, - це те, що я навмисне вирішив вписати тут".
  • Оскільки навіть вміст введених модулів є інкапсульований за змінною, яку ви призначаєте, і весь код виконується всередині обмеженого обсягу, сюрпризи та зіткнення стають дуже неймовірними. Набагато, набагато менш ймовірно, що щось із однієї з ваших залежностей буде випадково змінити глобальну змінну, якщо ви це не усвідомлюєте, або що ви це зробите. (Це може буває, але вам, як правило, доводиться виходити зі свого шляху, щоб це зробити, з чимось на зразок window.variable. Одна аварія, яка все ще має тенденцію, називається this.variable, не розуміючи цього this насправді window в поточному контексті.)
  • Якщо ви хочете перевірити окремий модуль, ви можете дуже легко знати: саме те, що ще (залежностей) впливає на код, який працює в модулі? І тому, що ви явно ін'єктуєте все, ви можете легко зловживати тими залежностями.

Для мене, використання модулів для інтерфейсного коду зводиться до: робота в набагато вужчому контексті, що простіше піддавати роз'ясненню та перевірці, а також більшої впевненості в тому, що відбувається.


Процес використання синтаксису модуля CommonJS / Node займає близько 30 секунд. Всередині даного JS-файлу, який буде модулем, ви спершу оголошуєте будь-які незалежні параметри, які ви хочете використовувати, як це:

var React = require('react');

Всередині файлу / модуля ви робите все, що зазвичай б, і створюєте якийсь об'єкт або функцію, яку ви хочете викрити зовнішнім користувачам, називаючи це можливо myModule.

У кінці файлу ви експортуєте все, що хочете поділитися зі світом, як це:

module.exports = myModule;

Потім, щоб використовувати робочий процес на основі CommonJS в браузері, ви будете використовувати такі засоби, як Browserify, щоб захопити всі ці окремих модульних файлів, інкапсулювати їх вміст під час виконання та ін'єкційувати їх один в одного, якщо це необхідно.

І, оскільки модулі ES6 (які, швидше за все, ви перейдете до ES5 з Babel або подібними) отримують широке визнання і працюють як в браузері, так і в Node 4.0, слід згадати про хороший огляд з них також.

Докладніше про шаблони для роботи з модулями в ця колода.


EDIT (лютий 2017): Facebook Пряжа це дуже важлива потенційна заміна / доповнення для npm в ці дні: швидкий, детерміністичний, офлайновий пакетний менеджмент, який спирається на те, що вам дає npm. Варто подивитися на будь-який проект JS, особливо тому, що його легко поміняти в / з.


256
2017-07-26 03:12



Рада, що ця відповідь була тут, інші популярні відповіді не згадують цю деталь. npm змушує вас писати модульний код. - Juan Mendes


2017-жовтня оновлення

Bower нарешті був не підтримується. Кінець історії.

Старша відповідь

З Mattias Petter Johansson, розробник JavaScript у Spotify:

У майже всіх випадках більш доречним є використання Browserify та npm над Bower. Це просто краще рішення для упаковки для зовнішніх додатків, ніж Bower. У Spotify ми використовуємо npm для пакетування цілих веб-модулів (html, css, js), і він працює дуже добре.

Bower сама як менеджер пакетів для Інтернету. Було б чудово, якби це було правдою - менеджер пакетів, який зробив моє життя кращим, як розробник інтерфейсу, буде чудовим. Проблема полягає в тому, що Bower не пропонує спеціалізованих інструментів для цієї мети. Вона пропонує NO інструменти, які я знаю про те, що npm не має, і особливо ніхто, який особливо корисний для фронт-розробників. Інтерфейсний розробник просто не має ніякої користі використовувати Bower за npm.

Ми повинні припинити використовувати агрегат і об'єднати навколо npm. На щастя, це те, що стається:

Module counts - bower vs. npm

За допомогою браузеру або веб-пакета, це надзвичайно легко об'єднати всі ваші модулі в великі minified файли, що є чудовим для продуктивності, особливо для мобільних пристроїв. Не так з Bower, що вимагатиме значно більше робочої сили, щоб отримати такий же ефект.

npm також пропонує вам можливість одночасно використовувати кілька версій модулів. Якщо ви ще не зробили значного розвитку додатків, це може спочатку вразити вас як погану справу, але, коли ви пройдете декілька нападів Залежність пекла ви зрозумієте, що маючи можливість мати кілька версій одного модуля, це чудова особливість. Зауважте, що npm містить дуже зручний дедупе інструмент що автоматично гарантує, що ви використовуєте тільки дві версії модуля, якщо ви насправді мати до - якщо два модулі обох може використовувати одну версію одного модуля, вони будуть. Але якщо вони не можу, у вас дуже зручно.

(Зауважте, що Вебпак і згорнути як правило, вважаються кращими, ніж Browserify на серпень 2016 року.)


117
2017-07-04 10:48



webpack і npm ще краще я думаю .. - refactor
<sarcasm> Будь ласка, майте на увазі, що навіть проект "npm" "hello world" потребує більше 300 модулів для запуску ... </ sarcasm>: O - Mariusz Jamro
Я не згоден з тим, що "великі мініфайли файли" є "чудовими для продуктивності, особливо для мобільних пристроїв". Зовсім навпаки: обмежена пропускна здатність вимагає невеликих файлів, завантажених за вимогою. - Michael Franzl
Не дуже хороший порад. Більшість пакетів npm є лише версією nodejs. Якщо ви не виконуєте JavaScript на бекенда, або у вас немає модульної системи на місці, кількість пакетів не має значення, тому що Bower буде відповідати вашим потребам набагато краще - Gerardo Grignoli
@ GerardoGrignoli: Боуер на своєму шляху. - Dan Dascalescu


Bower підтримує одну версію модулів, вона лише намагається допомогти вам вибрати правильний / найкращий для вас.

Управління залежності Javascript: npm vs bower vs volo?

NPM краще для модулів вузлів, оскільки існує модульна система, і ви працюєте локально. Bower корисно для браузера, оскільки в даний час існує лише глобальний обсяг, і ви хочете бути дуже вибірковими щодо версії, з якою ви працюєте.


43
2017-07-19 20:59



Я відчуваю, що Сіндр згадує про це, говорячи про вкладену залежність. - Games Brainiac
@GamesBrainiac, ваш правильний, просто подумав, я поставив це в мої власні слова. - Sagivf
@ Сагів Це такі НЕ ваші власні слова, якщо ви не є також самими, хто дав початкову відповідь тут - dayuloli
@ Савив Там нічого поганого з копіюванням ** відповідні частини від інших відповідей, якщо вони самі не дали відповіді тут. Він просто трохи підняв мене, якби ви сказали "просто подумав, що я поставив це своїми словами". Кредит повинен йти туди, де надається кредит. - dayuloli
Я не знаю, чому ви, хлопці, підібрали цю відповідь так багато. У цьому відповіді мені дійсно є нова інформація / перспектива. - Calvin


Моя команда відійшла від Bower і перейшла до npm, оскільки:

  • Програмне використання було болючим
  • Інтерфейс Bower постійно мінявся
  • Деякі функції, такі як URL-адреса, повністю зламані
  • Використання обох Bower і npm в одному і тому ж проекті болісно
  • Ведення поля bower.json у версії синхронізовано з git-тегами є болючим
  • Контроль вихідного коду! = Управління пакетом
  • Підтримка CommonJS не проста

Докладніше див "Чому моя команда використовує npm замість bower".


31
2018-02-16 21:04





Знайдено це корисне пояснення від http://ng-learn.org/2013/11/Bower-vs-npm/

З одного боку, npm створювався для встановлення модулів, що використовуються в середовищі node.js, або інструменти розробки, створені за допомогою node.js, наприклад, karma, lint, minifiers і так далі. npm може встановлювати модулі локально в проекті (за замовчуванням в node_modules) або глобально для використання декількома проектами. У великих проектах спосіб вказувати залежності полягає у створенні файлу під назвою package.json, який містить список залежностей. Цей список розпізнається за допомогою npm при запуску npm install, який потім завантажує та встановлює їх для вас.

З іншого боку, bower був створений для управління зовнішнім інтерфейсом. Бібліотеки, такі як jQuery, AngularJS, підкреслення тощо. Подібно до npm, є файл, у якому ви можете вказати список залежностей bower.json. У цьому випадку ваші зовнішні інтерфейси встановлюються запуском bower install, яка за замовчуванням встановлює їх у папку bower_components.

Як видно, хоча вони виконують подібне завдання, вони орієнтовані на дуже різний набір бібліотек.


14
2017-10-03 00:08



З появою Росії npm dedupe, це трохи застаріло. Побачити Відповідь Маттіаса. - Dan Dascalescu


Для багатьох людей, що працюють з node.js, основною перевагою bower є керування залежністю, які взагалі не є JavaScript. Якщо вони працюють з мовами, які збираються на JavaScript, npm може бути використаний для управління деякими з їх залежностей. однак, не всі їхні залежності будуть модулями node.js. Деякі з тих, що складаються з JavaScript, можуть мати дивовижне мовчання конкретного джерела мови, що змушує їх передавати в скомпільований для JavaScript варіант, коли користувач очікує вихідний код.

Не все в пакеті npm має бути скриптом JavaScript, але для пакунків бібліотеки npm, принаймні деякі з них повинні бути.


4
2017-10-11 20:42



Це повідомлення в блозі npmjs каже: "Ваш пакет може містити що-небудь, незалежно від того, є це ES6, JS на стороні клієнта чи навіть HTML та CSS. Це речі, які, природно, виявляються поруч із JavaScript, тому їх розміщуйте там". - Dan Dascalescu
Існує різниця між може містити, і повинен включати. Звичайно, вони можуть містити щось, але взагалі вони повинен включати якийсь інтерфейс для commonJS. Адже це "менеджер пакетів вузлів". Частина про Це речі, які природно виявляються поряд з Javascript


Bower і Npm є менеджерами пакетів для JavaScript.

Боуер

Bower створюється виключно для фронт-розробки. Вона використовує плосне дерево залежностей, яке вимагає лише однієї версії для кожного пакунка, зменшуючи завантаження сторінки. В основному це спрямовано на мінімальне завантаження ресурсів. Вона має менше учасників, і тому процес розвитку є повільним.

Bower має файл конфігурації bower.json. У цьому файлі ми можемо зберегти конфігурацію для Bower, як потрібні нам залежності, а також дані про ліцензії, опис, ім'я та інше. Bower підходить для фронтальних пакетів, таких як jquery, кутовий, реагує, ember, нокаут, магістралі тощо.

Npm

Npm найчастіше використовується для керування модулями Node.js, але він також працює для інтерфейсу. Він використовує вкладене дерево залежностей, а також дерево залежностей. Це популярно і має багато учасників. Тож його нова версія завжди придумує захоплюючі функції.

Npm має файл конфігурації під назвою package.json. У цьому файлі ми можемо зберегти конфігурацію для Npm, наприклад, які потрібні нам залежності, а також дані про ліцензії, опис, ім'я та інше. Npm забезпечує залежностей та DevDependencies. Залежностей буде завантажувати та підтримувати зовнішні файли, такі як Jquery, Angular і так далі. DevDependencies буде завантажувати та підтримувати такі інструменти розробки, як Grunt, Gulp, JSHint тощо.

Це, очевидно, не працює на передній панелі, тому що ми потребуємо jQuery у наших проектах. Нам потрібна лише одна копія jQuery, але коли інший пакет вимагає jQuery, то він ще раз скачати ще одну копію jQuery. Це один з основних недоліків Npm.

Основна примітка: Причиною того, що багато проектів використовують обидва варіанти, вони використовують Bower для інтерфейсних пакетів та Npm для інструментів розробника. Помноження менеджера пакетів у вашому проекті робить ваш робочий процес важче. Npm 3 в поєднанні з переглядати або webpack це шлях зараз.


1
2018-01-07 09:26