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


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


1603


источник


Ответы:


НПМ чаще всего используется для управления модулями Node.js, но он также работает для интерфейсов в сочетании с Browserify и / или $ npm dedupe,

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

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

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

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


Ресурсы


1820



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

На npm FAQ :

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

На осенять Домашняя страница:

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

Как вы можете видеть, он рекурсивно устанавливает некоторые зависимости. Зависимость 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 по-прежнему по-разному по сравнению с 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



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

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

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

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

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

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

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

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

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

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

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

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

  • Все, что внутри модуля эффективно 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 или аналогичных), получают широкое признание и работают как в браузере, так и в узле 4.0, мы должны упомянуть хороший обзор из них.

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


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


255



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

Bower наконец-то осуждается , Конец истории.

Более старый ответ

От Mattias Petter Johansson, разработчика JavaScript в Spotify :

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

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

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

Module counts - bower vs. npm

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

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

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


117



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

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

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


43



My team moved away from Bower and migrated to npm because:

  • Programmatic usage was painful
  • Bower's interface kept changing
  • Some features, like the url shorthand, are entirely broken
  • Using both Bower and npm in the same project is painful
  • Keeping bower.json version field in sync with git tags is painful
  • Source control != package management
  • CommonJS support is not straightforward

For more details, see "Why my team uses npm instead of bower".


31



Found this useful explanation from http://ng-learn.org/2013/11/Bower-vs-npm/

On one hand npm was created to install modules used in a node.js environment, or development tools built using node.js such Karma, lint, minifiers and so on. npm can install modules locally in a project ( by default in node_modules ) or globally to be used by multiple projects. In large projects the way to specify dependencies is by creating a file called package.json which contains a list of dependencies. That list is recognized by npm when you run npm install, which then downloads and installs them for you.

On the other hand bower was created to manage your frontend dependencies. Libraries like jQuery, AngularJS, underscore, etc. Similar to npm it has a file in which you can specify a list of dependencies called bower.json. In this case your frontend dependencies are installed by running bower install which by default installs them in a folder called bower_components.

As you can see, although they perform a similar task they are targeted to a very different set of libraries.


14



For many people working with node.js, a major benefit of bower is for managing dependencies that are not javascript at all. If they are working with languages that compile to javascript, npm can be used to manage some of their dependencies. however, not all their dependencies are going to be node.js modules. Some of those that compile to javascript may have weird source language specific mangling that makes passing them around compiled to javascript an inelegant option when users are expecting source code.

Not everything in an npm package needs to be user-facing javascript, but for npm library packages, at least some of it should be.


4



Bower and Npm are package managers for javascript.

Bower

Bower is created solely for the front-end development. It uses flat dependency tree, requiring only one version for each package, reducing the page load. It mainly aims for minimal resource load. It has less contributors and so development process is slow.

Bower has a configuration file called bower.json. In this file we can maintain the configuration for Bower like which dependencies we need and license details, description, name and so on. Bower is suitable for front-end packages like jquery, angular, react, ember, knockout, backbone and so on.

Npm

Npm is most commonly used for managing Node.js modules, but it works for the front-end too. It uses nested dependency tree as well as flat dependency tree. It is popular and has a lot of contributors. So its new version always comes up with exciting features.

Npm has a configuration file called package.json. In this file we can maintain the configuration for Npm like which dependencies we need and license details, description, name and so on. Npm provides Dependencies and DevDependencies. Dependencies will download and maintain the front-end files like Jquery, Angular and so on. DevDependencies will download and maintain development tools like Grunt, Gulp, JSHint and so on.

This obviously doesn't work that well on the front-end, because we need jQuery in our projects. We need only one copy of jQuery, but when another package requires jQuery, then it will download again one more copy of jQuery. This is one of the main drawbacks of Npm.

Key Note : The reason many projects use both is that they use Bower for front-end packages and Npm for developer tools. Multiplying package manager in your project make your workflow harder. Npm 3 coupled with browserify or webpack is the way to go now.


1