Управление зависимостями JavaScript: npm против bower против volo [закрыто]

160

Как вы сравниваете npm, bowerа volo?

Все три можно использовать для установки зависимостей JavaScript для проекта пользовательского интерфейса. Я понимаю, что npmэто более конкретный узел.

Итак, когда использовать что?

npmдо сих пор стоит на расстоянии, но bowerи , как voloпредставляется, решение точно такая же проблема, хотя я не могу нарисовать линию между npmи bower-volo.

Югаль Джиндл
источник
1
Если вы читаете этот вопрос и хотите получить ответ от 2015 года, см. Мой обновленный ответ.
густавохенке
2
Bower может быть объединен в Npm довольно скоро.
Дан Даскалеску

Ответы:

104

Описание, которое лучше всего описывает разницу между npm и bower: npm управляет модулями JavaScript, называемыми пакетами, а Bower управляет внешними компонентами (например, css, html и JavaScript), называемыми компонентами. Npm также используется для установки беседки. Вот обширная статья о npm и bower (не распространяется на volo), в ней много деталей.

strangeloops
источник
88
Это не очень хорошее описание. Npm, безусловно, можно использовать для установки внешних компонентов.
БТ
Хотя я заметил, что некоторые библиотеки "frontend" на npm заброшены в пользу своих коллег-бауэров. Возьмем, к примеру, Ember , который не был опубликован в течение года.
briangonzalez
4
@Nate Название просто там, где это началось. NPM теперь является системой управления пакетами очень общего назначения. Я регулярно использую npm для установки интерфейсных модулей. Нет никакой разницы в использовании NPM для модулей commonjs, против amd, против всего остального. Вы также можете использовать npm для модулей, не поддерживающих JavaScript. Следовательно, это просто не разница между npm и bower. Независимо от того, называете ли вы их пакетами или компонентами, они одинаковы в том смысле, что они представляют собой наборы произвольных файлов.
BT
2
Это очень вводящий в заблуждение ответ, учитывая, что у Бауэра нет политики в отношении html, css и javascript. У npm также нет политики, за исключением того, что почти все на npm написано, по крайней мере, для поддержки commonjs и иногда других форматов. Вы можете поместить html и css в пакеты npm так же, как вы можете использовать bower. На npm есть много пакетов только для веб-интерфейса, включая пакеты css и html.
подстак
3
Если вы используете browserify , npm - идеальный менеджер пакетов. Я не думаю, что имеет значение, какой менеджер пакетов вы используете, но я бы лично выбрал только один на проект.
Eruant
72

осенять

Он по-прежнему очень популярен среди разработчиков переднего плана, хотя у него очень мало функций. Каждый интерфейсный пакет использует его. Существует также инициатива по слиянию беседок в npm .

Bower оптимизирован для клиентской части и поддерживает только плоские деревья зависимостей, то есть каждую библиотеку необходимо использовать только один раз (поскольку дорого отправлять клиенту разные версии одной и той же библиотеки), а ограничения зависимостей должны разрешаться пользователем ,

Вы можете ожидать найти что-нибудь, что связано с интерфейсом, в реестре bower ( bower search <some keyword>) - на мой взгляд, это самое большое преимущество bower по сравнению с другими менеджерами пакетов.

вол

Я до сих пор не использовал его более 5 минут в течение многих лет. Не знаю об этом, но из того, что я вижу, он включает в себя инструмент для сборки, который очень знаком пользователям Grunt.

НПМ

Да, npm означает Node Package Manager. Но в настоящее время вы можете использовать его для всего; люди больше не только npm installищут вещи и ожидают, что они будут работать только в среде Node. Например, существует множество пакетов npm для Twitter Bootstrap .

Npm оптимизирован для использования на стороне сервера с вложенным деревом зависимостей. Каждая зависимость может иметь свои зависимости, которые могут иметь свои собственные, и так далее. Это устраняет конфликты версий зависимостей, поскольку каждая зависимость может использовать свою собственную версию, например Underscore. Однако следующая версия npm 3 сгладит дерево зависимостей :

С npm @ 3 ваша директория node_modules будет намного более плоской. Все ваши зависимости и большинство ваших зависимостей (и (sub) + зависимостей) будут находиться рядом друг с другом на верхнем уровне. Только при наличии конфликтов модули будут установлены на более глубоких уровнях. Это должно облегчить жизнь пользователям Windows.

Некоторые преимущества использования npm:

  • Он используется всеми другими менеджерами пакетов (компонент, bower, volo, JSPM и т. Д.);
  • Позволяет использовать сценарии сборки;
  • Для анализа пакетов на основе npm доступно множество инструментов

npm - менеджер пакетов для JavaScript.

скриншот npmjs.com


По состоянию на февраль 2013 года мое мнение было следующим. Пожалуйста, не принимайте это во внимание больше.

НПМ

Лучше придерживаться этого, когда вы работаете с Node-проектом, очень мало проектов, которые также доступны для браузеров ...

осенять

Бауэр сейчас поп-парень. У них под капотом много проектов, и разработчики проектов хотели бы держать их в актуальном состоянии в реестре Bower ...

Обидно, что он иногда немного глючит.

вол

С тех пор я не пробовал volo более 5 минут, но, насколько я вижу, он выглядит более гибким, чем беседка.

Негативным моментом для volo является то, что их проекты сильно устарели.

gustavohenke
источник
19
На npm существуют тысячи модулей, которые либо работают только в браузерах, либо работают как в узлах, так и в браузерах. У многих из них даже есть значки ci, которые точно указывают, в каких браузерах они работают. Большинство всего на bower et all, вероятно, на npm.
подстак
Я не понимаю, что для проекта, такого как ngBoilerplate, нужно использовать bower, хотя это уже зависит от npm для установки
lolski
5
Что такое «поп парень»? Является ли "поп" аббревиатура. для "популярных"?
Брайан Оукли
4
На вашем скриншоте npm обозначает руководство по ядерному планированию;)
Джим Джонс
24

Кажется, они решают одну и ту же проблему, но для разных сред / миров. NPM для nodejs и volo, беседка для браузера.

Правда в том, что вы можете использовать NPM также для управления javascript и css для браузера. Ничто не мешает вам сделать это. В этом смысле использование NPM кажется мне более естественным, чем управление двумя разными инструментами для одной и той же цели.

Кажется, у bower есть больше доступных пакетов, по крайней мере, для более популярных. Но скоро jQuery также будет доступен в NPM напрямую, и, вероятно, все остальные библиотеки будут следовать той же тенденции.

На мой взгляд, поскольку существуют такие инструменты, как browserify и webmake , которые помогают использовать модули узлов в браузере, больше нет реальной необходимости в bower или volo , если они не предлагают что-то другое для вас (конкретный модуль существует только в их реестры).

И Воло, и Бауэр тоже хороши, но, с моей точки зрения, если вы уже используете NPM, лучше придерживаться его.

Обратите внимание, что вы можете использовать NPM для управления клиентскими зависимостями даже без использования browserify или webmake . В большинстве проектов, над которыми я работаю, после установки модулей npm я запускаю сценарий, чтобы развернуть их в том месте, где их использует мое клиентское приложение. Иногда я использую grunt для объединения этого файла с другими js-файлами, а иногда я ссылаюсь на него непосредственно из файлов шаблонов моих веб-приложений. В любом случае это личное предпочтение. Другие могут найти Bower или Volo более легкими в использовании, поскольку они более естественны в своих рабочих процессах.

Рой Риохас
источник
1
Хорошо иметь конкурирующие решения для той же проблемы. Есть идеи, почему yeomanпроект решил предложить нового менеджера пакетов, когда он у нас уже был npm? (Это был зрелый, известный и богатый набор функций). Эта мысль заставляет меня чувствовать, что я все еще упускаю фактический смысл.
Югаль Джиндл
1
Не совсем, но, как вы сказали, иногда забавно изобретать велосипед, просто потому, что вы можете, а иногда, делая это, вносятся некоторые улучшения, пытаясь решить ту же проблему. Не совсем то, почему они решили сделать новый, кроме того, чтобы облегчить поиск разработчиков пакетов. Не все разработчики интерфейсов имеют опыт работы с узлами, я думаю, это главная причина таких проектов, как Bower. Постарайтесь сделать это проще для неузловых пользователей, я просто угадываю здесь.
Рой Риохас
Я думаю, что они хотели отделить хлопоты npmв пользу простоты интерфейса. Следовательно, для развития веб-интерфейса.
Югаль Джиндл
15

Большое преимущество Bower над NPM состоит в том, что его управление зависимостями обеспечивает использование одной версии компонента (тогда как NPM работает с наличием разных копий / версий в качестве зависимостей разных модулей). Это ОЧЕНЬ ХОРОШАЯ вещь, потому что она предотвращает раздутость JavaScript на стороне клиента из-за необходимости включать несколько копий компонента в разных версиях. Включение нескольких копий модуля является центральным для того, как работает управление зависимостями NPM, и поэтому NPM совершенно не подходит для управления пакетами на стороне клиента.

Следствием вышесказанного является то, что сопровождающие и покупатели пакетов Bower должны быть внимательнее, чтобы сохранить номера версий зависимостей, чтобы избежать конфликтов, но это стоит того. И я нахожу, что модули NPM часто выпускают мажорные, второстепенные и патч-релизы, поэтому управление зависимостями NPM тоже не является ложем роз.

wheresrhys
источник
3
Это верно только в том случае, если вы предоставляете свой код внешнего интерфейса прямо из папки, в которую менеджер пакетов помещает эти файлы. В моем случае у меня либо есть скрипт сборки для обработки файлов less / js, либо browserify для создания пакета из этих файлов. Так что это не очень большая проблема в моем случае. Распространяемый код всегда имеет правильные версии, даже когда другие подкомпоненты могут иметь дубликаты во время разработки, они никогда не попадут в производство.
Рой Риохас
даже если вам непреднамеренно требуются (в качестве подзависимости) две разные версии одной и той же зависимости? Я думаю, что в этом случае вы не правы
wheresrhys
Обычно мне не требуются модули, которые я не контролирую, поэтому они всегда будут правильными ... если по неосторожности модуль попытается потребовать данный модуль из подкладочных, сборка будет неудачной. Нет смысла использовать беседку в моем случае, никакой выгоды не было
Рой Риохас
Таким образом, можно с уверенностью сказать, что npm избегает дублирования модулей в коде на стороне клиента, если у вас есть контроль над всем деревом зависимостей. Это, конечно, не относится к подавляющему большинству вещей, над которыми я работаю, и, вероятно, не к большинству проектов, использующих менеджер зависимостей для включения клиентских модулей.
wheresrhys
1
Если вы не работаете с коллажами, ваше дерево зависимостей не будет таким сложным, по крайней мере для стороннего кода. Большинство библиотек js экспортируют один глобальный объект, поэтому, используя browserify-shim, вы можете убедиться, что можете использовать их из глобальной области видимости, следовательно, всегда версией, которую вы контролируете. Я хочу сказать, что вы можете добиться того же самого без необходимости использования другого менеджера пакетов поверх того, который у вас уже есть. В конце концов, это может быть вопросом предпочтений. Всегда есть компромиссы.
Рой Риохас
5

Я знаю, что это не входит в суть вопроса, но есть и другая альтернатива. Jam JS - http://jamjs.org/ Одна интересная вещь заключается в том, что в варенье у него есть возможности:

jam compile output.js

Кто-то должен сделать еще один менеджер пакетов и назвать его: yapm :)

Брюс Лим
источник
5
Ваше желание исполнено: github.com/rlidwka/yapm : P
alex
1
Я подумал о менеджере зависимостей на стороне браузера, но думаю, что эта работа для обоих: p Вот почему я не могу запускать стартапы, все мои идеи уже были продуманы.
Брюс Лим
@BruceLim Да, каждый раз, когда мы думаем, что у нас есть хорошая идея, всегда есть другие люди, которые ее уже получили.
Эван Ху