8 Вопрос: В чем разница между Bower и npm?

вопрос создан в Thu, Mar 2, 2017 12:00 AM

В чем принципиальная разница между bower и npm? Просто хочу что-то простое и понятное. Я видел, как некоторые из моих коллег используют bower и npm взаимозаменяемо в своих проектах.

    
1696
  1. Связанный ответ stackoverflow.com/a/21199026/1310070
    2014-03-19 12: 54: 55Z
  2. 2014-07-24 15: 47: 03Z
  3. Ответ на этот вопрос устарел. Может кто-нибудь сказать нам, что делать в 2016 году, если мы используем npm 3, который поддерживает плоскую зависимость? Какая разница между npm3 и bower, и какая сейчас лучшая практика?
    2016-10-05 11: 48: 01Z
  4. Итог, @amdev: бауэр объявлен устаревшим. Npm (или пряжа, которая является лишь небольшой разницей) - это то, где он находится. Я не знаю ни о каких жизнеспособных альтернативах.
    2018-01-07 15: 32: 00Z
8 ответов                              8                         

У всех менеджеров пакетов есть много минусов. Вам просто нужно выбрать, с чем вы можете жить.

История

npm начал управлять модулями node.js (поэтому пакеты входят в node_modules по умолчанию), но это работает также для внешнего интерфейса в сочетании с Browserify или WebPack.

Bower создан исключительно для внешнего интерфейса и оптимизирован с учетом этого.

Размер репо

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

Бауэр имеет гораздо меньшее количество пакетов.

Обработка стилей и т. д.

Бауэр включает стили и т. д.

npm ориентирован на JavaScript. Стили загружаются отдельно или требуют что-то вроде npm-sass или sass-npm.

Обработка зависимостей

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

Вложенное дерево зависимостей означает, что ваши зависимости могут иметь свои собственные зависимости, которые могут иметь свои собственные, и так далее. Это позволяет двум модулям требовать разные версии одной и той же зависимости и при этом работать. Обратите внимание, что начиная с npm v3, дерево зависимостей по умолчанию будет плоским (экономия места) и будет гнездиться только там, где это необходимо, например, если двум зависимостям требуется собственная версия Underscore.

В некоторых проектах используется то, что они используют Bower для интерфейсных пакетов и npm для инструментов разработчика, таких как Yeoman, Grunt, Gulp, JSHint, CoffeeScript и т. д.

Ресурсы

1879
2018-06-29 11: 57: 23Z
  1. Почему вложенное дерево зависимостей не работает так хорошо на внешнем интерфейсе?
    2014-01-19 16: 41: 09Z
  2. Может ли интерфейсный пакет npm также не быть плоским деревом зависимостей? Я сталкиваюсь с вопросом "зачем нам 2 менеджера пакетов?" дилемма.
    2014-01-24 02: 51: 36Z
  3. Что вы подразумеваете под "плоским деревом зависимостей"? Плоское дерево - это что - список? Тогда это не дерево.
    2014-10-17 02: 42: 58Z
  4. На самом деле путь - это тоже дерево. Это просто особый случай. Из WikiPedia: «В математике, а точнее в теории графов, дерево - это неориентированный граф, в котором любые две вершины соединены ровно одним путем».
    2014-12-25 17: 20: 44Z
  5. npm 3 теперь поддерживает плоское дерево зависимостей.
    2015-11-21 06: 55: 44Z

Этот ответ является дополнением к ответу Синдре Сорхуса. Основное различие между npm и Bower заключается в том, как они обрабатывают рекурсивные зависимости. Обратите внимание, что они могут использоваться вместе в одном проекте.

В FAQ по npm : (ссылка archive.org от 6 сентября 2015 г.)

  

Гораздо сложнее избежать конфликтов зависимостей без вложенности   зависимостей. Это фундаментально для того, как работает 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

Как вы можете видеть, он устанавливает некоторые зависимости рекурсивно. Зависимость A имеет три установленных экземпляра!

Бауэр:

 
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 для пакетов, которые вы хотите опубликовать на своих веб-страницах (например, время выполнения , где вы избегаете дублирования), и используйте npm для других вещей, таких как тестирование, сборка, оптимизация, проверка и т. д. (например, время разработки , где дублирование менее важно).

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

npm 3 по-прежнему работает иначе, чем Бауэр. Он установит зависимости глобально, но только для первой версии, с которой он столкнется. Другие версии установлены в дереве (родительский модуль, затем 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 . р>     

356
2018-07-05 13: 33: 22Z
  1. Теперь это почти клише, когда «разработка программного обеспечения - это компромиссы». Это хороший пример. Нужно выбрать либо большую стабильность с npm , либо минимальную загрузку ресурсов с bower.
    2015-06-10 00: 38: 17Z
  2. @ Шрек Я неявно заявляю, что вы на самом деле можете использовать оба. У них разные цели, как я заявляю впоследний абзац Это не компромисс в моих глазах.
    2015-06-10 08: 25: 10Z
  3. Ааа, я понял, что неправильно вас понял. Или я недостаточно внимательно прочитал. Спасибо за разъяснения. :-) Хорошо, что оба могут быть использованы без компромисса.
    2015-06-10 14: 38: 44Z
  4. @ AlexAngas Я добавил обновление для npm3. У этого все еще есть некоторые главные различия по сравнению с Бауэром. npm, вероятно, всегда будет поддерживать несколько версий зависимостей, а Bower - нет.
    2016-01-18 10: 13: 38Z
  5. npm 3 становится ближе к бауэру;)
    2017-03-21 06: 40: 19Z

TL; DR. Самое большое различие в повседневном использовании - это не вложенные зависимости ... это различие между модулями и глобальными переменными.

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

Я удивлен, однако, что никто не объяснил одно из самых фундаментальных различий между Bower и npm. Если вы прочитаете ответы выше, вы увидите слово «модули», часто используемое в контексте npm. Но это упоминается случайно, как будто это может быть просто разница в синтаксисе.

Но это различие модулей и глобальных (или модулей и «скриптов»), возможно, является наиболее важным отличием между Bower и npm. Подход npm для размещения всего в модулях требует, чтобы вы изменили способ написания Javascript для браузера, почти наверняка в лучшую сторону.

Подход Бауэра: глобальные ресурсы, такие как теги <script>

В корне Bower идет о загрузке простых старых файлов сценариев. Что бы ни содержали эти файлы скриптов, Бауэр загрузит их. По сути, это означает, что Бауэр точно так же, как и все ваши скрипты из старых <script> в <head> вашего HTML.

Итак, тот же базовый подход, к которому вы привыкли, но вы получаете некоторые удобные возможности автоматизации:

  • Раньше вам приходилось включать зависимости JS в репозиторий проекта (при разработке) или получать их через CDN. Теперь вы можете пропустить этот дополнительный вес загрузки в репо, и кто-то может сделать быстрый bower install и мгновенно получить то, что ему нужно, локально.
  • Если зависимость Bower затем определяет свои собственные зависимости в своих bower.json, они также будут загружены для вас.

Но кроме этого, Бауэр не меняет то, как мы пишем JavaScript . Ничего из того, что происходит внутри файлов, загружаемых Bower, вообще не должно меняться. В частности, это означает, что ресурсы, предоставляемые в скриптах, загружаемых Bower, будут (обычно, но не всегда) по-прежнему определяться как глобальные переменные , доступные из любого места в контексте выполнения браузера.

Подход npm: общие JS-модули, явное внедрение зависимостей

Весь код в Node land (и, следовательно, весь код, загружаемый через npm) структурирован как модули (в частности, как реализация формат модуля CommonJS или теперь как модуль ES6). Итак, если вы используете NPM для обработки зависимостей на стороне браузера (через Browserify или что-то еще, что делает ту же работу), вы будете структурировать свой код так же, как это делает Node.

Более умные люди, чем я, взялись за вопрос «Почему модули?», но вот краткая сводка:

  • Все, что находится внутри модуля, по сути namespaced , что означает, что это больше не глобальная переменная, и вы не можете случайно ссылаться на нее, не намереваясь.
  • Все, что находится внутри модуля, должно быть преднамеренно введено в определенный контекст (обычно в другой модуль), чтобы использовать его
  • Это означает, что у вас может быть несколько версий одной и той же внешней зависимости (скажем, lodash) в различных частях вашего приложения, и они не будут конфликтовать /конфликтовать. (Это происходит на удивление часто, потому что ваш собственный код хочет использовать одну версию зависимости, но одна из ваших внешних зависимостей определяет другую, которая конфликтует. Или у вас есть две внешние зависимости, каждая из которых хочет иметь другую версию.)
  • Поскольку все зависимости вводятся вручную, яДля конкретного модуля очень легко рассуждать о них. Вы точно знаете: «Единственный код, который мне нужно учитывать при работе над этим, - это то, что я намеренно выбрал для внедрения здесь» .
  • Поскольку даже содержимое внедренных модулей инкапсулировано за переменной, которой вы его назначаете, и весь код выполняется внутри ограниченной области, неожиданности и коллизии становятся очень маловероятными. Гораздо менее вероятно, что что-то из одной из ваших зависимостей будет случайно переопределять глобальную переменную без вашего понимания или того, что вы это сделаете. (Это может произойти, но вам обычно приходится изо всех сил делать это, например, с 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, мы должны упомянуть хороший обзор , а также.

Подробнее о шаблонах для работы с модулями в этой колоде .

РЕДАКТИРОВАТЬ (февраль 2017 г.): пряжа Facebook является очень важной потенциальной заменой /дополнением для npm в наши дни: быстро, детерминированное автономное управление пакетами, основанное на том, что дает вам npm. Это стоит посмотреть на любой проект JS, особенно потому, что его так легко поменять местами.

РЕДАКТИРОВАТЬ (май 2019 г.) «Бауэр наконец-то устарел . история." (h /t: @DanDascalescu, ниже, для краткого изложения.)

И, хотя пряжа все еще активна , большая часть импульса для нее вернулся к npm, как только он принял некоторые из ключевых особенностей пряжи.

    
264
2019-05-11 17: 41: 03Z
  1. Рад, что этот ответ был здесь, другие популярные ответы не упоминают эту деталь. npm заставляет вас писать модульный код.
    2016-05-13 13: 06: 28Z
  2. Мне очень жаль, из народа, который очень мало заботится обо всех размышлениях в парвалах javascript, но так происходит, что он запускает бизнес, который использует небольшое веб-приложение , Недавно был вынужден попробовать npm от использования bower с инструментарием, который мы используем для разработки проклятых веб-приложений. Я могу сказать вам, что самая большая разница в времени ожидания, npm занимает много времени. Помните, что компиляция мультфильма xkcd с парнями, играющими в мечах, выкрикивая «компиляцию» своему боссу; это в значительной степени то, что npm добавил к беседке.
    2018-11-21 21: 00: 25Z

2017-октябрьское обновление

Бауэр наконец-то был устарелред . Конец истории.

Старый ответ

От Маттиаса Петтера Йоханссона , Разработчик JavaScript на Spotify :

  

Почти во всех случаях более уместно использовать Browserify и npm поверх Bower. Это просто лучшее упаковочное решение для интерфейсных приложений, чем Bower. В Spotify мы используем npm для упаковки целых веб-модулей (html, css, js), и это работает очень хорошо.

     

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

     

Мы должны прекратить использовать беседку и консолидироваться около нпм. К счастью, это то, что происходит :

 Модуль рассчитывает - бауэр против npm

  

С помощью browserify или webpack становится очень легко объединить все ваши модули в большие миниатюрные файлы, что очень важно для производительности, особенно для мобильных устройств. Не так с Бауэром, который потребует значительно больше труда, чтобы получить тот же эффект.

     

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

(обратите внимание, что веб-пакет и накопительный пакет считается лучше, чем Browserify по состоянию на август 2016 г.) р>     

127
2017-11-16 21: 40: 48Z
  1. веб-пакет и npm еще лучше, я думаю ..
    2016-08-30 13: 58: 52Z
  2. < sarcasm > Имейте в виду, что даже для проекта npm "hello world" требуется более 300 модулей для запуска ... < /sarcasm > : O
    2016-12-11 18: 36: 31Z
  3. Я не согласен с тем, что "большие минимизированные файлы" являются "потрясающими по производительности, особенно для мобильных устройств". Скорее наоборот: ограниченная пропускная способность требует небольших файлов, загружаемых по требованию.
    2017-04-09 14: 03: 52Z
  4. Не очень хороший совет. Большинство пакетов npm являются только бэкэндом nodejs. Если вы не используете javascript в бэкэнде или у вас нет модульной системы, количество пакетов не имеет значения, потому что Bower будет лучше соответствовать вашим потребностям
    2017-04-11 17: 59: 15Z
  5. 2017-04-12 08: 30: 45Z

Бауэр поддерживает одну версию модулей, он только пытается помочь вам выбрать правильный /лучшийодин для вас.

  

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

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

    
45
2017-05-23 11: 55: 01Z
  1. Мне кажется, что Синдре упоминает об этом, когда говорит о вложенной зависимости.
    2014-07-19 21: 21: 01Z
  2. @ GamesBrainiac, ваш правильный ответ, просто подумал, что я бы сказал это своими словами.
    2014-07-20 11: 01: 47Z
  3. @ Sagivf Это НЕ ваши собственные слова, если только вы не являетесь тем, кто предоставил первоначальный ответ здесь
    2015-03-03 06: 36: 25Z
  4. @ Sagivf Нет ничего плохого в том, чтобы копировать ** соответствующие части ответов других, если они сами не предоставили здесь ответ. Это меня немного напрягло, когда ты сказал: «Просто подумал, что я выразил это своими словами». Кредит должен идти туда, где он должен.
    2015-03-04 10: 39: 14Z
  5. Я не знаю, почему вы так много выбрали для этого ответа. В этом ответе есть действительно новая информация /перспектива.
    2015-11-30 22: 04: 44Z

Моя команда переехала из Бауэра и перешла на npm, потому что:

  • Программное использование было болезненным
  • интерфейс Бауэра постоянно менялся
  • Некоторые функции, такие как сокращение URL, полностью не работают
  • Использование Bower и npm в одном и том же проекте сопряжено с большими трудностями
  • Поддерживать синхронизацию поля версии bower.json с тегами git
  • Контроль версий! = управление пакетами
  • Поддержка CommonJS не проста

Подробнее см. «Почему моя команда использует вместо этого npm беседки ".

    
33
2015-11-21 04: 04: 51Z

Нашел это полезное объяснение в 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.

     

Как видите, хотя они выполняют аналогичную задачу, они нацелены на совсем другой набор библиотек.

    
17
2014-10-10 03: 26: 45Z
  1. С появлением npm dedupe это немного устарело. См. ответ Маттиаса .
    2015-07-04 10: 49: 58Z

Для многих людей, работающих с node.js, основным преимуществом bower является управление зависимостями, которые вообще не являются javascript. Если они работают с языками, которые компилируются в javascript, npm может использоваться для управления некоторыми из их зависимостей. однако не все их зависимости будут модулями node.js. Некоторые из тех, которые компилируются в javascript, могут иметь странные искажения, специфичные для исходного языка, что делает передачу их скомпилированным в javascript неэлегичной опцией, когда пользователи ожидают исходный код.

Не все в пакете npm должно быть ориентированным на пользователя javascript, но для пакетов библиотеки npm, по крайней мере, некоторые из них должны быть.

    
7
2014-10-11 21: 27: 09Z
  1. В этом посте npmjs говорится: «Ваш пакет может содержать что угодно, будь то ES6, JS на стороне клиента или даже HTML и CSS. Это вещи, которые естественным образом появляются вместе с JavaScript, поэтому разместите их там».
    2015-07-04 10: 28: 22Z
  2. Существует различие между может содержать и должно включать . Конечно, они могут содержать все что угодно, но в целом они должны включать некоторый интерфейс к commonJS. В конце концов, это «менеджер пакетов узлов». Часть о Эти вещи, которые естественно появляются вместе с Javascript , очень важны. Есть много вещей, которые тангенциально связаны с javascript, которые естественно не появляются вдоль этого.
    2015-12-09 02: 43: 01Z
источник размещен Вот
Другие вопросы