TL; DR: самая большая разница в повседневном использовании - это не вложенные зависимости ... это разница между модулями и глобальными переменными.
Я думаю, что предыдущие плакаты хорошо освещали некоторые основные различия. (Использование npm вложенных зависимостей действительно очень полезно для управления большими и сложными приложениями, хотя я не думаю, что это самое важное различие.)
Я удивлен, однако, что никто явно не объяснил одно из самых фундаментальных различий между Bower и npm. Если вы прочитаете ответы выше, вы увидите слово «модули», часто используемое в контексте npm. Но это упоминается случайно, как будто это может быть просто разница в синтаксисе.
Но это различие между модулями и глобальными (или модулями и «скриптами»), возможно, является наиболее важным отличием между Bower и npm. Подход npm для помещения всего в модули требует, чтобы вы изменили способ написания Javascript для браузера, почти наверняка в лучшую сторону.
Бауэр подход: глобальные ресурсы, как <script>теги
В корне Bower о загрузке простых старых файлов сценариев. Что бы ни содержали эти файлы скриптов, Бауэр загрузит их. Что в основном означает, что Bower - это то же самое, что включить все ваши скрипты в простой старый <script>в <head>ваш HTML.
Итак, тот же базовый подход, к которому вы привыкли, но вы получаете некоторые удобные возможности автоматизации:
- Раньше вам приходилось включать JS-зависимости в репозиторий проекта (при разработке) или получать их через CDN. Теперь вы можете пропустить этот дополнительный вес загрузки в репо, и кто-то может быстро
bower installи мгновенно получить то, что ему нужно, локально.
- Если зависимость Bower затем указывает свои собственные зависимости
bower.json, они также будут загружены для вас.
Но кроме этого, Бауэр не меняет то, как мы пишем JavaScript . Ничего из того, что происходит внутри файлов, загружаемых Bower, вообще не должно меняться. В частности, это означает, что ресурсы, предоставляемые в скриптах, загружаемых Bower, будут (обычно, но не всегда) по-прежнему определяться как глобальные переменные , доступные из любого места в контексте выполнения браузера.
Подход npm: общие JS-модули, явное внедрение зависимостей
Весь код в Node land (и, следовательно, весь код, загружаемый через npm) структурирован как модули (в частности, как реализация формата модуля CommonJS , или теперь как модуль ES6). Итак, если вы используете NPM для обработки зависимостей на стороне браузера (через Browserify или что-то еще, что делает ту же работу), вы будете структурировать свой код так же, как это делает Node.
Более умные люди, чем я, взялись за вопрос «Почему модули?», Но вот краткая сводка:
- Все, что находится внутри модуля, фактически является пространством имен , что означает, что оно больше не является глобальной переменной, и вы не можете случайно ссылаться на него, не намереваясь.
- Все, что находится внутри модуля, должно быть намеренно введено в конкретный контекст (обычно в другой модуль), чтобы использовать его
- Это означает, что вы можете иметь несколько версий одной и той же внешней зависимости (скажем, lodash) в разных частях вашего приложения, и они не будут конфликтовать / конфликтовать. (Это происходит на удивление часто, потому что ваш собственный код хочет использовать одну версию зависимости, но одна из ваших внешних зависимостей задает другую, которая конфликтует. Или у вас есть две внешние зависимости, каждая из которых требует своей версии.)
- Поскольку все зависимости вводятся вручную в конкретный модуль, их очень легко рассуждать. Вы точно знаете: «Единственный код, который мне нужно учитывать при работе над этим, - это то, что я намеренно выбрал для внедрения здесь» .
- Поскольку даже содержимое внедренных модулей инкапсулировано за переменной, которой вы назначаете его, и весь код выполняется в ограниченной области, неожиданности и коллизии становятся очень маловероятными. Гораздо менее вероятно, что что-то из одной из ваших зависимостей будет случайно переопределять глобальную переменную без вашего понимания или того, что вы это сделаете. (Это может случиться, но вам, как правило, приходится делать все возможное, чтобы сделать это, с чем-то вроде
window.variable. Единственная авария, которая все еще имеет тенденцию происходить, это присвоение this.variable, а не осознание того, что thisна самом деле находится windowв текущем контексте.)
- Когда вы хотите протестировать отдельный модуль, вы можете очень легко узнать: что еще (зависимости) влияет на код, который выполняется внутри модуля? И, поскольку вы явно вводите все, вы можете легко высмеивать эти зависимости.
Для меня использование модулей для внешнего кода сводится к: работе в гораздо более узком контексте, который легче рассуждать и тестировать, и большей уверенности в происходящем.
Это займет всего около 30 секунд, чтобы научиться использовать синтаксис модуля CommonJS / Node. Внутри данного файла 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, ниже, для краткого изложения.)
И, несмотря на то, что Yarn все еще активен , большая часть импульса вернулась к npm, как только он принял некоторые из ключевых функций Yarn.
