В чем разница между Bower и npm?

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

на НПМ FAQ: (archive.org ссылка от 6 сентября 2015)

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

On беседке сайт:

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

короче говоря, npm стремится к стабильности. Bower стремится к минимальной ресурсной нагрузке. Если вы нарисуете структуру зависимостей, вы увидите это:

НПМ:

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

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

npm 3 все еще делает вещи по-другому по сравнению с Bower. Он будет устанавливать зависимости глобально, но только для первой версии, с которой он сталкивается. Остальные версии устанавливаются в дереве (Родительский модуль, затем node_modules).

• [папки node_modules]
  • деп версии 1.0
  • dep B v1.0
    • деп версии 1.0 (использует корень версия)
  • dep C v1.0
    • dep a v2.0 (эта версия отличается от корневой версии, поэтому это будет вложенная установка)

для получения дополнительной информации, я предлагаю читать документы npm 3

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

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

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

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

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

в root, Bower о загрузке простых старых файлов сценариев. Все файлы скрипта содержать, беседки загрузит их. Это в основном означает, что Bower так же, как и все ваши скрипты в plain-old <script>с <head> вашего HTML.

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

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

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

подход npm: общие модули JS, явная инъекция зависимостей

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

умные люди, чем я, решили вопрос " почему модули?но вот краткое резюме:

• что-нибудь внутри модуля эффективно в пространстве имен, что означает, что это больше не глобальная переменная, и вы не можете случайно ссылаться на нее без намерения.
• что-либо внутри модуля должно быть намеренно введено в определенный контекст (обычно другой модуль), чтобы использовать его
• это означает, что вы можете иметь несколько версий одной и той же внешней зависимости (скажем, lodash) в разных частях вашего приложения, и они не будут сталкиваться/конфликтовать. (Это происходит удивительно часто, потому что ваш собственный код хочет использовать одну версию зависимости, но одна из ваших внешних зависимостей указывает другую, которая конфликтует. Или у вас есть две внешние зависимости, каждая из которых хочет другую версию.)
• поскольку все зависимости вводятся вручную в конкретный модуль, очень легко рассуждать о них. Вы точно знаете:"единственный код, который мне нужно учитывать при работе над этим, - это то, что я намеренно выбрал для инъекции вот".
• потому что даже содержание вводят модули капсулированные за переменной вы назначаете его, и весь код выполняется в ограниченной области, сюрпризы и столкновения становятся очень маловероятными. Гораздо, гораздо менее вероятно, что что-то из одной из ваших зависимостей случайно переопределит глобальную переменную, не осознавая этого, или что вы это сделаете. (Это can случается, но вы обычно должны идти из вашего пути, чтобы сделать это, с чем-то вроде window.variable. Один несчастный случай, который до сих пор обычно назначает this.variable, не осознавая, что this на самом деле window в текущем контексте.)
• когда вы хотите протестировать отдельный модуль, вы можете очень легко узнать: что именно (зависимости) влияет на код, который работает внутри модуля? И, поскольку вы явно вводите все, вы можете легко издеваться над этими зависимостями.

для меня применение модули для интерфейсного кода сводятся к: работе в гораздо более узком контексте, о котором легче рассуждать и тестировать, и большей уверенности в том, что происходит.

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

var React = require('react');

внутри файла/модуля, вы делаете все обычно вы создаете какой-то объект или функцию, которую хотите предоставить внешним пользователям, называя ее, возможно,myModule.

в конце файла вы экспортируете все, что хотите поделиться с миром, например:

module.exports = myModule;

затем, чтобы использовать рабочий процесс на основе CommonJS в браузере, вы будете использовать такие инструменты, как Browserify, чтобы захватить все эти отдельные файлы модулей, инкапсулировать их содержимое во время выполнения и вводить их друг в друга по мере необходимости.

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

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

изменить (февраль 2017): Facebook пряжа является очень важной потенциальной заменой / дополнением для НПМ в эти дни: быстрое, детерминированное, автономное управление пакетами, основанное на том, что дает npm. Стоит посмотреть на любой проект JS, тем более, что его так легко поменять местами.

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

Бауэр, наконец, был устаревший. Конец истории.

старшего ответа

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

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

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

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

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

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

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

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

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

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

моя команда отошла от Bower и перешла к npm, потому что:

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

дополнительные сведения см. В разделе "почему моя команда использует npm вместо bower".

нашел это полезное объяснение от http://ng-learn.org/2013/11/Bower-vs-npm/

с одной стороны, npm был создан для установки модулей, используемых в узле.среда JS, или средства разработки, построенные с использованием узлов.js такая карма, корпия, minifiers и так далее. npm может устанавливать модули локально в проекте (по умолчанию в node_modules ) или глобально для использования несколькими проектами. В больших проектах можно указать зависимости, создав файл с именем пакет.json, который содержит список зависимостей. Этот список распознается npm при запуске npm install, который затем загружает и устанавливает их для вас.

с другой стороны, bower был создан для управления зависимостями вашего интерфейса. Библиотеки, такие как jQuery, AngularJS, underscore и т. д. Подобно npm, он имеет файл, в котором вы можете указать список зависимостей, называемых bower.формат JSON. В этом случае ваши зависимости frontend устанавливаются путем запуска Bower install, который по умолчанию устанавливает их в папку bower_components.

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

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

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

Bower и Npm являются менеджерами пакетов для javascript.

беседке

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

Bower имеет файл конфигурации под названием bower.формат JSON. В этом файле мы можем поддерживать конфигурацию для Bower например, какие зависимости нам нужны и сведения о лицензии, описание, имя и так далее. Bower подходит для фронтальных пакетов, таких как jquery, angular, react, ember, knockout, backbone и так далее.

НПМ

Npm чаще всего используется для управления узлом.модули js, но он работает и для front-end. Он использует вложенное дерево зависимостей, а также плоское дерево зависимостей. Он популярен и имеет много участников. Поэтому его новая версия всегда придумывает захватывающие особенности.

Npm имеет файл конфигурации с именем package.формат JSON. В этом файле мы можем поддерживать конфигурацию для Npm, например, какие зависимости нам нужны и сведения о лицензии, описание, имя и так далее. Npm предоставляет зависимости и DevDependencies. Зависимости будут загружать и поддерживать интерфейсные файлы, такие как Jquery, Angular и т. д. DevDependencies будет загружать и поддерживать инструменты разработки, такие как Grunt, Gulp, JSHint и так далее.

Это, очевидно, не работает это хорошо на переднем конце, потому что нам нужен jQuery в наших проектах. Нам нужна только одна копия jQuery, но когда другой пакет требует jQuery, он снова загрузит еще одну копию jQuery. Это один из главных недостатков НПМ.

Внимание : причина, по которой многие проекты используют оба, заключается в том, что они используют Bower для интерфейсных пакетов и Npm для инструментов разработчика. Умножение диспетчера пакетов в проекте усложняет рабочий процесс. НПМ 3 в сочетании с browserify или webpack теперь это путь.