Bower как пользоваться: Bower — пакетный менеджер для web – Знакомство с Bower / Sandbox / Habr

Bower — пакетный менеджер для web

Bower — пакетный менеджер для web. Первое подробное руководство в рунете. Пришло время разобрать bower «по косточкам».

Всем привет! Меня зовут Дмитрий Ковальчук и я представляю вам первый урок в курсе «Bower — подробное руководство». Мы пройдем путь от основ, до лучших практик и продвинутых техник.

Начнём с определения. Bower — это пакетный менеджер для web. У него масса преимуществ и им пользуются если не все, то большинство современных опытных frontend специалистов. Сегодня стыдно не знать Bower и это не просто мэйнстрим. Bower действительно упрощает нам жизнь.

Как установить bower?

Для того, чтобы работать с Bower, у вас должны быть установлены node.js c npm, а также git. Я работаю из консоли git bash в оболочке conemu. Вам, особенно если вы новичок, рекомендую также работать именно в git bash. Если у вас нет git и git bash, то скачайте его с официального сайта git-scm.com

Если вы пользователь windows, не забудьте во время установки перевести radio button в положение «Run Git from the Windows Command Prompt». Таким образом, git автоматически будет добавлен в ваш PATH, что в будущем сэкономит вам силы и сбережет ваши нервы.

Что касается node.js и npm, то тут проверить очень просто:

Если вы вместо версии видите что-то вроде «comand not found», тогда жмите на паузу и идите на официальный сайт nodejs nodejs.org и скачивайте последнюю версию продукта.

Если с git и npm повросов и сомнений больше нет, тогда мы можем преступить к работе.

Давайте теперь установим сам bower

И сразу проверим его версию

Отлично. bower у нас установлен, теперь мы шаг за шагом будем погружаться в особенности работы с ним.

Поиск, инсталляция, обновление и удаление библиотек

Обычно, начинающие разработчики, для того, чтобы скачать какую-либо библиотеку, фреймворк или плагин, лезут в google, находят официальный сайт или репозиторий этого продукта и скачивают необходимые файлы. Вспомните сами, сколько раз вы заходили на jquery.com, чтобы скачать последнюю версию любимой всеми javascript программистами библиотеки?

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

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

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

ПОИСК

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

Или прямо в консоли. Давайте попробуем найти jquery

Кстати, многие команды имеют свои укороченные варианты

Как мы видим, в консоли появился огромный список библиотек. Это различные плагины, которые в своём названии или описании имеют слово jquery. Огромный список свидетельствует о колоссальных размерах сообщества frontend разработчиков, которые пишут эти библиотеки и регистрируют их в bower. Чтобы узнать более детальную информацию о библиотеке, например получить список версий продукта, используется команда info

УСТАНОВКА

Для установки любого нового пакета (или библиотеки) используется команда install или её сокращенный вариант i. Все вновь установленные библиотеки будут попадать в папку bower_components по-умолчанию.

bower install jquery#1.6.4

bower install jquery#1.6.4

Давайте теперь выведем прямо в консоль список установленных библиотек

Как теперь быстро добавить ссылки на скаченные библиотеки в index.html? Один из способов использовать команду list с ключем —path

ОБНОВЛЕНИЕ

Для обновления библиотек используется команда update, однако, чтобы полноценно с ней работать, нужно создать файл манифест bower.json, а мы этого пока не умеем. Если мы прямо сейчас попытаемся написать

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

Давайте попробуем и посмотрим, что у нас получится

Bower начинаем с нами советоваться, как поступить ему поступить! Он сообщает, что у нас уже установлен jquery#1.6.4 и мы можем либо оставить всё, как было, либо установить jquery#2.0.3. Мы выбираем второй вариант.

УДАЛЕНИЕ

jquery бесследно исчез из папки bower_components

Всё, первое знакомство с bower прошло успешно. Вы уже можете начинать работать и радоваться сэкономленному времени. Однако самое интересное еще впереди.

Инициализация Bower пакета. Файл манифест bower.json.

Чтобы ощутить следующие преимущества работы с Bower, необходимо создать так называемый файл «манифест» bower.json. Сделать это можно либо вручную, просто создав этот файл, либо в автоматическом режиме, набрав в консоли команду.

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

Давайте взглянем на него подробнее

• name — единственное обязательное поле, т.е. остальные мы можем просто удалить, если пока они нам не нужны
• version — версия вашего пакета. Обязательно 3 цифры
• authors — авторы
• ignore — перечень путей, которые мы хотим проигнорировать
• dependencies — другие пакеты, от которых зависит ваш проект (на продакшене)

Обратите внимание, что normalize.css записался в наш файл манифест в объект dependencies. Это очень важный момент.

Давайте установим теперь библиотеку jquery, но уже немного не так, как мы это делали раньше. Мы явно укажем, что jquery обязательно должен быть в продакшен версии нашего проекта. Т.е., без него проект отдавать заказчику нельзя. Отныне мы все библиотеки, от которых зависит наш проект будем устанавливать с ключем —save.

А теперь представьте другую ситуацию. Она, конечно, встречается крайне редко (в отличае от того же npm и gulp, где ситуация обратная), однако вы должны знать все нюансы. Есть библиотеки, которые нужны только разработчику, т.е. нам с вами, именно в процессе разработки, но не нужны на продакшене.

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

К примеру, мне на ум пришла библиотека Zepto.js, которая очень похожа на облегченную версию jquery. Zepto не поддерживает старые версии internet explorer (младше 10ой версии), в отличие от jquery. Представим, что для наших каких-то собственных нужд мы будем использовать Zepto, но в продакшен версии продукта будет именно jquery. Так вот, такие библиотеки, которые нужно только разработчику, но не нужны на продакшене, необходимо писать не в dependencies, а в devDependencies. Делается это очень просто

Теперь давайте еще раз пройдем процедуру удаления, но на этот раз учтём файл манифест. Удаляя библиотеку физически, нам нужно подчищать и bower.json. В этих целях применяется всё тот же ключ —save (-S) или —save-dev (-D). Давайте удалим все наши библиотеки, но сделаем это корректно. Обратите внимание, что удалять, ровно как и устанавливать библиотеки можно просто перечисляя их одну за другой через пробел.

bower uninstall jquery normalizr.css -S

bower uninstall jquery normalizr.css -S

Подробнее про версии и обновление библиотек

Настоятельно рекомендую вам прочитать про «Семантическое версионирование«, чтобы вы понимали, как обновляя библиотеки не потерять обратную совместимость.

Давайте поговорим про версии более подробно. Еще раз установим jquery и запишем информацию о нём в файл манифест

У нас установилась последняя на день написания данного видеокаста версия библиотеки, а именно версия 2.1.4

В bower.json появилась запись «~2.1.4». Тильда означает, что jquery в моём проекте можно обновлять, но не выше, чем до версии 2.2.0

Есть еще один символ, который вы будете встречать довольно часто — «домик». Если мы напишем «^2.1.4», то это будет означать, что jquery в моём проекте можно обновлять, но, на этот раз, не выше, чем до версии 3.0.0

Для наглядности я подготовил для вас такую табличку

Давайте теперь проведем эксперимент. Установим

В файле bower.json появилась запись jquery»: «1.0.1», добавим ~ перед версией и наберем

Теперь версия jquery станет 1.0.4

А если заменим ~ на ^

Теперь версия jquery станет 1.11.3

А если заменим ^ на latest, то получим версию 2.1.4

ВНИМАНИЕ! На момент просмотра этого скринкаста, возможно выйдут и более свежие версии библиотек. Главное, чтобы вы поняли суть.

Чтобы преступить к следующему шагу, давайте специально, в академических целях установим старинную версию jquery

Подробнее про зависимости

Все вы знаете или слышали про фреймворк bootstrap. Его также можно установить при помощи bower. Многие из вас также знают, что bootstrap зависит от jquery. bower также это знает.

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

bower i bootstrap -S

bower понимает, что для корректной работы последней версии bootstrap необходим jquery#1.9.1 и сообщает нам о возможных неприятностях со старой версией jquery.

bower предлагает нам самим решить, как поступить в данном случае. Давайте выберем вариант bootstrap#3.3.4 и jquery#1.9

теперь, если мы наберем команду

bower list

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

Давйте вручную отредактируем bower.json. Напишем, что нам подходит версия jquery#2.1.4

Еще раз убедимся, что всё в порядке

bower list

Отлично! Видите, как здорово, bower никогда не даст нам запутаться в версиях и не поставит под угрозу работу нашего проекта.

Дополнительные настройки bower

У bower есть целый ряд дополнительных настроек, таких, как, например место расположения скаченных библиотек.

По-умолчанию, bower устанавливает все зависимости в папку bower_components. Однако, мы можем поменять как имя папки, так и её место расположение. Делается это очень просто: необходимо создать рабочий файл, который должен называться .bowerrc

В нём пишем

{ «directory» : «app/bower» }

{ «directory» : «app/bower» }

Теперь перенесем уже существующую папку в новое место. Для этого в консоли наберем

mv bower_components app/bower

mv bower_components app/bower

И установим новую библиотеку tooltipster

Наслаждайтесь результатом!

Рекомендуемые курсы

Bower — зачем нужен, установка и настройка

На данный момент, Bower один инструмент front-end разработчиков по всему миру. Наряду с Grunt и Gulp, он вызывает много вопросов у начинающих разработчиков.
Что же такое Bower? Говоря по простому, Bower управляет пакетами, которые вы захотите использовать в проекте. Важно отметить, что в данном случае «пакет» имеет несколько другое значение, чем библиотека или фреймворк.

Bootstrap — это пакет. jQuery — это тоже пакет.
Приведем цитату с официального сайта:
Веб-сайты сделаны из многих частей — фреймворки, библиотеки, css и javascript файлы. Bower управляет всеми составляющими.

Почему надо использовать Bower?

Как разработчик, вы должны стремиться к тому, чтобы максимально автоматизировать свою работу. Неэффективно грузить файлы библиотек и фреймоворков в проект по отдельным файлам. Используя Bower вам не нужно будет заниматься загрузкой вручную.
Например, вы хотите установить Angular в ваш проект. Вместо того, чтобы искать в интернете, где скачать файлы Angular или подключить CDN, вы можете запустить команду bower install angular и bower установит фреймворк в ваш проект.

Использование bower.json и .bowerrc

bower.json и .bowerrc — это два основных файла для работы с bower.

Bower.json

Настроив bower.json вы можете использовать одни и те же пакеты в разных проектах. По принципу работы он очень похож на package.json. Он состоит из различных зависимостей для конкретного проекта.
Эти пакеты определяются в виде JSON объектов.
Для того, чтобы установить пакеты, надо создать файл bower.json с зависимостями в папке вашего проекта и запустить команду bower install.
Дополнительно, вы можете использовать командную строку для добавления нужных пакетов в bower.json. Для этого надо использовать команду bower install с флагом —save.

Пример файла bower.json

{ «name»: «example», «version»: «0.0.1», «dependencies»: { «jquery»: «latest», «bootstrap-sass»: «latest», «font-awesome»: «latest», «html5shiv»: «latest», «respond»: «latest» } }

{     «name»: «example»,     «version»: «0.0.1»,     «dependencies»: {         «jquery»: «latest»,         «bootstrap-sass»: «latest»,         «font-awesome»: «latest»,         «html5shiv»: «latest»,         «respond»: «latest»     } }

В данном примере мы задаем имя проекта «example», версию «0.0.1» и зависимости. После запуска команды bower install, будут установлены пакеты jQuery, Bootstrap Sass, FontAwesome, html5shiv и respond. Найти нужные пакеты вы можете на сайте http://bower.io/search/

.bowerrc

RC файлы — это конфигурационные файлы для программ в Unix операционных системах. .bowerrc используется для определения конфигурации Bower, задания путей для сохранения библиотек в вашем проекте.
Например, если вы хотите, чтобы все библиотеки сохранились в папке public/libs, задайте в .bowerrc следующую строку:

{ «directory»: «dev/libs/» }

{   «directory»: «dev/libs/» }

Если вы не укажете путь сохранения, Bower сохранит все пакеты в папку bower_components.

Как правильно использовать bower + gulp + sass? — Хабр Q&A

Здравствуйте.

Вот некоторые вопросы
1) Испытываю некоторый диссонанс от использования связки bower + gulp + sass + foundation (или bootstrap — аналогично)
Как собирать проект?

• Если использовать напрямую из bower_components, то не получиться отключать ненужные компоненты фреймворка, т.к. после bower update мой файл foundation.scss будет просто перезаписан.
  
• Если копировать foundation в мою папку с исходниками (она же src/sass), то теряется смысл использования bower. Да, нам не нужно будет заходить на сайт, чтобы скачать нужную версию фреймворка, но и автоматическое обновление, одна из основных фишек bower, теряется — мы же всё вручную копируем.
  

2) У многих bower плагинов отсутствуют как таковые scss файлы. Приходится опять же вручную всё оттуда копировать/переводить в scss. Кроме того, если подключать плагины, имеющие картинки, то приходится также менять пути или копировать картинки из bower в папку assets. При обновлении процедуру копирования из bower_components в папку исходников проекта приходится повторять, т.е. делать ненужную работу. Проблема.

3) Как таковые проблемы отсутствуют только с js файлами — но см ниже.

Видел, что в случаях 2-3 можно всё автоматизировать — захардкодить пути каждого отдельного плагина в gulp, сделать автоматическую замену путей и подобные костыли. Но при добавлении/удалении каждого плагина в bower работа увеличивается на порядок, так как нужно править и gulpfile. Кроме того, многие разработчики плагинов грешат сменой путей при выходе новой версии, что как бы тоже может доставить неудобства. В общем этот вариант считаю кривым и даже не берусь использовать.

А как в этих трёх случаях корректно всё делать, я не понимаю. Так как bower явно задумывался не для ручного копирования, всё должно быть проще и автоматизированнее, с возможностью быстрого обновления всех плагинов из консоли. Или я слишком идеализирую возможности bower’a?

И последний вопрос, чисто по галпу.
4) Является ли вообще нормальной практикой прописывать вручную пути для какждого отдельного плагина/файла? Я именно это называю хардкодить. На мой взгляд, опять же, таск менеджеры задуманы для автоматической сборки проекта, чтобы добавление/удаление плагинов и файлов в проект не вызывали затруднений и лишней работы в gulpfile. Или опять же я слишком на многое рассчитываю от данного инструмента и постоянно редактировать gulpfile это нормально?

Тема получилась объёмной, т.к. наболело, но если ответите хотябы на 1 вопрос — уже буду очень благодарен.

Зачем нужен менеджер пакетов, или почему именно Bower — «Хакер»

Содержание статьи

Все материалы сюжета:

Надоело ходить на сайты JavaScript-библиотек и качать архивы каждый раз, как надо добавить на сайт очередной jQuery-плагин? Бовер сделает все сам.

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

Хождение по сайтам библиотек, скачивание и распаковка архивов, копирование файлов в проект — все это заменяется парой команд в терминале.

У многих языков программирования есть стандартные менеджеры пакетов, которыми разработчики пользуются для установки всех библиотек: gem у руби, pip у питона и другие. У серверного яваскрипта есть npm (почему он не подходит для клиентского — дальше), а у клиентского яваскрипта до недавнего времени ничего не было. Было множество разных пакетных менеджеров (Jam, Component, Volo, Ender), но большинство из них так и не стали популярными, а от менеджера пакетов, которым не поставишь нужных библиотек, толку мало.

 

Почему не npm

Главное отличие npm и Бовера — подход к установке зависимостей пакетов. Npm устанавливает зависимости для каждого пакета отдельно, в папку этого пакета, потом так же ставит зависимости зависимостей и так далее. В клиентском яваскрипте это недопустимо: нельзя подключить на страницу две версии jQuery или любой другой библиотеки. В Бовере каждый пакет устанавливается один раз, и в случае конфликта зависимостей Бовер просто не станет устанавливать пакет, несовместимый с уже установленными.

Бовер — не стандартный менеджер пакетов для клиентского яваскрипта, но самый популярный: сейчас там больше 11 тысяч пакетов.

Бовер не навязывает пользователю свою систему сборки, разработчику пакетов — метод подключения библиотеки (AMD, CommonJS и другие). Все, что делает Бовер, — устанавливает нужные проекту пакеты подходящих версий вместе с их зависимостями. Другими словами: просто загружает файлы нужных библиотек и все, что нужно для их работы, в специальную папку. Остальное остается на усмотрение разработчика.

 

Установка Бовера

Для работы с Бовером тебе потребуются Node.js и Git. Установка предельно проста: npm install -g bower

Работа с пакетами

Попробуем что-нибудь установить, например jQuery:

bower install --save jquery

Флаг --save говорит Боверу, что он должен сохранить имя пакета и его версию в специальный файл со списком всех зависимостей проекта — bower.json. У нас такого файла еще нет, о чем и говорит строчка «No bower.json file to save to, use bower init to create one» в логе.

Создадим bower.json:

bower init

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

На вопрос «set currently installed components as dependencies?» нужно ответить «Yes» — все ранее установленные компоненты (в нашем случае это jQuery) автоматически попадут в созданный JSON-файл. А на вопрос «would you like to mark this package as private which prevents it from being accidentally published to the registry?» — тоже «Yes», если вы не делаете библиотеку, которую потом будете публиковать в Бовере.

Поставим еще несколько пакетов (можно устанавливать несколько пакетов сразу):

bower install --save social-likes jquery-icheck fotorama
bower list
bower check-new     Checking for new versions of 
the project dependencies..
bowertest#0.0.0 /Users/admin/bowertest
├── jquery#2.1.0 (2.1.1-beta1 available)
├─┬ jquery-icheck#1.0.2
│ └── jquery#2.1.0 (2.1.1-beta1 available)
└─┬ social-likes#3.0.2
  └── jquery#2.1.0

Команда bower list покажет список всех установленных пакетов. Ты увидишь, что все пакеты зависят от jQuery и что Бовер смог найти удовлетворяющую всех версию jQuery — 2.1.0. Каждый пакет устанавливается в свою папку внутри директории bower_components, вложенных пакетов нет, jQuery встречается только один раз. В корне проекта лежит созданный нами bower.json, но теперь там перечислены уже все пакеты, которые показывает bower list, а не только jQuery.

Для удаления пакетов используется команда

bower uninstall --save packageName.

 

INFO

Ты можешь спокойно удалять папку bower_components или добавить ее в свой .gitignore. Команда bower install (без дополнительных параметров) вернет все как было.

 

Развертывание проекта

Есть два подхода к развертыванию проектов:

1. В репозиторий добавляется только файл-манифест, и все пакеты устанавливаются во время развертывания проекта. Так в репозитории не хранится ничего лишнего, но, если во время развертывания проекта упадет гитхаб или другой сервер, с которого устанавливаются пакеты, будут проблемы.
2. В репозиторий добавляется и bower.json, и папка bower_components. Так развертывание не зависит от внешних серверов, но репозиторий раздувается десятками лишних файлов.

 

Семантические версии (semver)

Semver — это, во-первых, подход к версионированию библиотек: формат МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ и правила, по которым следует увеличивать то или иное число. А во-вторых — это способ описания требуемых версий зависимостей, который используют Бовер и npm.

При установке с флагом --save версии пакетов добавляются в bower.json в виде ~1.0.1. Тильда в начале говорит о том, что при установке будет выбрана версия 1.0.1 или с большим последним числом (ПАТЧ), если она есть. Таким образом, будет установлена версия с последними исправлениями ошибок, но полностью совместимая с той, что указана вbower.json.

 

Обновление зависимостей

В Бовере есть команда bower update, но она обновляет пакеты с учетом требований, описанных в bower.json. Например, если там требуется jQuery ~2.0.0, то он сможет обновить его, например, до 2.0.9, но 2.1.0 уже не поставит, потому что он не соответствует формуле ~2.0.0.

Для обновления пакетов (и bower.json) до действительно последних версий можно воспользоваться bower-update. Устанавливаем:

npm install -g bower-update

Запускаем:

bower-update

— и вуаля!

 

Поиск пакетов

Есть два способа найти нужный пакет: гиковский и обычный. Гиковский:

bower search jquery
Search results:
  jquery git://github.com/jquery/jquery.git
  jquery-ui git://github.com/components/jqueryui
    ...

Обычный: открыть в браузере bower.io/search/.

 

Автоматическая сборка

Бовер перекладывает проблемы сборки установленных пакетов на плечи разработчика.

Самый легкий способ — просто склеить JS-файлы Грантом, Галпом или любой другой системой сборки, которой ты пользуешься.

Я пользуюсь Грантом, поэтому расскажу, как склеивать пакеты им. О том, как пользоваться Грантом, была большая статья в июльском номере прошлого года, поэтому покажу сразу конфиг плагина grunt-contrib-concat:

concat: {
  main: {
    src: [
      'bower_components/jquery/jquery.min.js',
      'bower_components/fotorama/….js',
      'bower_components/jquery-icheck/….js',
      'bower_components/social-likes/
       social-likes.min.js',
      // Скрипты твоего сайта
      'scripts/*.js'
      ],
      dest: 'build/scripts.js'
   }
}

У этого способа есть много недостатков: тебе нужно смотреть имена файлов для каждого пакета и следить, чтобы файлы собирались в правильном порядке (например, jQuery должен быть выше, чем скрипты, зависящие от него). Плагин grunt-bower-concat может делать это сам: он автоматически склеивает все установленные зависимости в правильном порядке в один файл:

bower_concat: {
  all: {
    // Склеенный файл
    dest: 'build/_bower.js',
    // Пакеты, которые нужно исключить 
    // из сборки
    exclude: [ 
      // Если jQuery подключается 
      // с CDN Гугла
      'jquery',
      // Если подключаем скрипты в конце 
      // страницы; Modernizr нужно 
      // подключать в <head>
      'modernizr'
    ]
  }
},

concat: {
  main: {
    src: [
      'build/_bower.js',
      // Скрипты твоего сайта
      'scripts/*.js'
      ],
    dest: 'build/scripts.js'
  }
}

 

Bower – обзор пакетного менеджера

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

Что позволяет делать Bower?

Одной командой уставить и обновлять (до актуальных версий) библиотеки скриптов на JavaScript и стилей CSS.

Например, моментально ставить jQuery. И ещё десяток библиотек. А после, одной командой всё обновить, когда возникнет необходимость.

Установка

Начнём с официального сайта утилиты:

http://bower.io

Для установки необходимо набрать всего одну команду в консоли:

npm install -g bower

Разумеется, npm – это Node Package Manager, а это значит что на вашей машине должен быть установлен Node.JS.

Думаю, что установка Ноды не составит какого-либо труда. На всякий случай напомню адрес дистрибутива для Mac, Windows и Linux:

http://nodejs.org/download/

Дальше всё просто.

Как это работает

 

При помощи консоли переходите в рабочую директорию вашего сайта.

И выполняете команду на установку того или иного пакета.

bower install <package>

Вот пример с официального сайта:

# registered package 

$ bower install jquery 

# GitHub shorthand 

$ bower install desandro/masonry 

# Git endpoint 

$ bower install git://github.com/user/package.git 

# URL 

$ bower install http://example.com/script.js

Обратите внимание, что можно ставить не только из репозитория, но и, например, с Git.

При помощи команды bower search <package> можно поискать пакеты в официальном репозитории.

Также это можно сделать при помощи веб-интерфейса:

http://bower.io/search/

Тонкости

По умолчанию всё ставится в папку ./bower_components, что не всегда удобно. Ручное изменение имени папки приведёт к потери возможности автоматического обновления.

Поэтому, в случае необходимости, лучшим выходом из ситуации станет правка файла конфигурации рабочей папки утилиты.

Для начала необходимо создать файл конфигурации.

Он создаётся автоматически при установке любого пакета или же вручную, если мы вызовем следующую команду:

# cd ваша_рабочая_директория — предварительно перейдём туда, где будем устанавливать пакеты

bower init

В корне директории появится файл bower.json, который будет иметь следующий вид:

{
  "name": "Название пакета",
  "version": "1.0.0", // Версия
  "directory": "bower_components/", // А вот это и есть наша директория
  "dependencies": {
    "jquery": "*"
  }
}

Это обычный JSON-объект, как вы уже догадались.

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

Логично назвать её, например, vendor или assets.

Напоследок, вот небольшой видео-обзор от товарища Sorax:

Приятной работы с Bower.

Bower для всего | WebReference

Если вы не живёте в норе, то хорошо осведомлены о том, что JavaScript вращает всё вокруг нас. Многие из удивительных идей, что я обнаружил в экосистеме Rails, теперь вырвались в космос JavaScript и способствуют распространению замечательных продуктов. Три столпа: Yeoman, Bower и Grunt.

Проблема, которую мне нужно решить, следующая — какой лучший способ получить код некоторой библиотеки с Github и сделать его легко доступным для пользователей без клонирования проекта? Потому что это довольно отстало, не так ли?

Генераторы Yeoman

Первоначально я наткнулся на generator-sass-boilerplate, «Генератор Yeoman для быстрого скаффолдинга из стилей Sass». Это очень интересный подход для создания сложной библиотеки и позволяет пользователю настраивать установку. Но для простой библиотеки кода, которой, возможно, требуются только несколько функций и примесей, данный метод слишком накладной.

Bower — вот ответ

Недавно я наткнулся на новые посты, которые на самом деле рассказывают что есть Bower и что он лучше всего. И меня осенило, что это и есть ответ!

Для тех, кто не в курсе, Bower является чрезвычайно простым решением для управления фронтенд-пакетами.

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

Красота Bower в его простоте. У Bower есть реестр, но он не на 100% необходим. Общая команда такая: bower install <пакет>, где <пакет> может указывать на огромное число вариантов, что позволяет чрезвычайно просто делиться некоторым кодом. Прекрасно!

Придерживаясь темы «чрезвычайно просто» вы можете с помощью Bower легко вытащить хранилище в ваш проект без его клонирования. Даже если у него нет файла bower.json.

Например Stipe, библиотека для Compass которую я написал, не известна Bower вообще.

$ bower install git://github.com/Toadstool-Stipe/stipe.git

Запустите эту команду в любой папке и вы вытяните всё хранилище без истории Github. Это само по себе довольно интересно.

Начало работы с Bower

Начать довольно просто. Предполагая, что Node и npm уже установлен, выполните:

$ npm install -g bower

Установка пакета Bower

Я не буду здесь вдаваться в мельчайшие подробности, но 99% времени вам просто нужно выполнить:

$ bower install <пакет>

Как указано выше, существуют альтернативные методы установки, но основным решением является файл bower.json в хранилище и его регистрация в Bower.

Если в вашем проекте есть файл bower.json, о котором пойдёт речь в следующем разделе, вы можете добавить флаг —save при установке и это добавит библиотеку в качестве зависимости в ваш проект. Мило.

Когда вы распространяете проект, то пользователю, который его клонирует, достаточно только запустить $ bower install и он будет тянуть все внешние ресурсы. Красота!

Коммит или не коммит!?

Эта новая система создания и распространения ресурсов поднимает интересный вопрос — нужно ли коммитить все пакеты Bower или нет? В мире Ruby на самом деле Gem не является частью проекта, но связан с проектом и никогда не коммитится в систему контроля версий проекта. В этом новом JavaScript-мире зависимые пакеты Node и Bower являются ссылками в манифесте, подобно Gemfile в Ruby, но в действительности установлены в корневую папку проекта.

Существует целая дискуссия по этому вопросу. Я смотрю на это так — когда вы устанавливаете библиотеку Bower, вы оставляете её как зависимость или вносите модификации?

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

Создание нового пакета Bower

Создать новый пакет Bower снова на самом деле просто.

$ bower init

В консоли это инициализирует ряд вопросов, ответы на которые будут включены в новый созданный файл bower.json. Пишите что пожелаете, но всё что на самом деле нужно, это следующее:

{
  "name": "your-project",
  "version": "0.1.0"
}

И это всё на самом деле. Вы только что создали свою первую библиотеку ресурсов Bower. Теперь двигайтесь вперед и стройте — свои ресурсы, документацию и т. д., ваш пакет готов в любое время!

Для простого тестирования вспомните трюк $ bower install git://github.com/…? Запустите это с новым хранилищем и увидите, как оно устанавливается.

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

$ bower install bourbon

Запустив эту установку вы получите всё хранилище. Мне не нужно хранилище целиком, всё, что мне действительно требуется это папка dist/. Чтобы решить эту проблему, другой разработчик сделал форк Bourbon и создал новое хранилище с названием bower-bourbon:

$ bower install bower-bourbon

Выполнив эту установку вы на деле получите только то, что находится в папке dist/. Но эти форки заслуживают доверия?

ОБНОВЛЕНИЕ. До моего внимания довели, что при установке тянется версия Bourbon 3.2 Beta и она, кажется, не полностью функциональна. В этом разделе я не намерен говорить «плохой Bourbon», а просто показываю, что в некоторых случаях с помощью Bower вы получите больше библиотек, чем действительно хотите.

Регистрация Bower

После того, как пакет готов к выпуску, зарегистрируйте его в Bower. Критерии довольно простые:

1. убедитесь, что ваше хранилище содержит файл bower.json;
2. вы должны использовать семантическую версионность;
3. ваш пакет должен быть доступен через Git, например, на Github.

После того, как всё это у вас есть, выполните следующую команду с новым именем пакета и хранилищем Git:

$ bower register <имя пакета> <хранилище git>

Регистрация проходит безболезненно. После того, как вы получите зелёный свет на всё, сделайте проверку и выполните $ bower install <имя пакета>.

Bower и Sass

Bower и Sass — это библиотеки, которые удивительно сочетаются друг с другом. Есть небольшие хранилища по всему Github на Ruby Gem/Compass, но их сложность бывает слишком накладной. Вы должны сделать либо форк, либо клон или не дай бог, скопировать и вставить код в свой проект. Что? Мы не цивилизованные?

В мире Ruby разработчики привыкли к тому, что Gem и Compass установлены в безопасном неприкасаемом месте. Новый Gem добавляется в Gemfile и мы просто ссылаемся на библиотеку в проекте.

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

В новом мире JavaScript, библиотека добавляется в манифест bower.json или просто устанавливается, но вместо того, чтобы находиться в неопределённом месте, устанавливается в корень проекта. Это сохраняет всё простым с точки зрения установки, но означает, что Sass импортируется в относительную папку. Небольшая разница, но отличается от того, к чему мы привыкли.

Итак, как выглядит пакет Sass Bower? Давайте возьмём простой проект, который я создал с именем sass-icon-fonts. Этот пакет является просто парой примесей, которые позволяет разработчику легко создавать набор правил @font-face, а также быстро генерировать набор правил со шрифтовыми иконками. Мини-библиотека поставляется с инструкциями и очень простым API.

Теперь представив что вы создаёте Node-проект и хотите использовать этот пакет в качестве ресурса, выполните:

$ bower install sass-icon-fonts —save

Эта команда установит пакет и добавит зависимость в ваш файл bower.json. Создайте в корне проекта папку sass/, а внутри неё файл application.scss. В корне также находится папка bower_components. Для доступа к вашему файлу application.scss вам нужно импортировать относительный путь к библиотеке, как показано в следующей строке:

@import "../bower_components/sass-icon-fonts/_ico-font.scss";

Предыдущий пример работает и я считаю его приемлемым, но не замечательным. Роясь дальше в Grint-Sass API я обнаружил функцию includePaths. Она позволяет вам установить путь импорта.

options: {
  includePaths: [
    './bower_components/bower-bourbon'
  ]
}

Теперь у нас есть это в Gruntfile.js и вы можете легко ссылаться на основной файл манифеста библиотеки через простой импорт Sass, например, так:

@import "bourbon";

Bower в npm

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

Да, да, вы можете. В файле package.json просто расширьте объект scripts и передайте команду bower install. Вот почему я действительно люблю эту штуку!

"scripts": {
  "install": "bower install"
}

Теперь, при запуске npm install вы не только установите все пакеты Node, но и заодно пакеты Bower. Прекрасно!

Bower за фаерволом

Если вы оказались за фаерволом, который не разрешает протокол git://, это можно исправить. Для начала я предлагаю сделать вручную клон с использованием протокола https://, чтобы убедиться, что это действительно проблема. Если протокол https:// работает, то вы можете сделать следующее обновление:

git config --global url."https://"

Спасибо Stack Overflow!

Резюме

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

Не нужны больше форки, клонирование, удаление папки .git/, достаточно просто включить библиотеку в проект. Я смотрю на создание модулей Sass также в совершенно новом свете. Не то, чтобы Compass был сложен, но Bower освобождает меня от нескольких зависимостей. А это было реальной проблемой во многих проектах.

Автор и редакторы

Автор: Дейл Санде

Последнее изменение: 17.04.2016

Редакторы: Влад Мержевич

Как правильно организовать структуру проекта с использованием gulp + bower? — Хабр Q&A

Делаю тестовый проект с целью изучения gulp и его модулей, bowerи т.д.
Никак не могу понять, как правильно организовать структуру проекта в том случае, если необходимо скопировать основные файлы компонента из /bower_components в папку, куда собирается проект (/dist), в папку, скажем, assets

После определенного времени, проведенного с Google, подключил main-bower-files, который и копирует основные файлы компонента из /bower_components в /dist/assets
Но это не совсем то, что хотелось бы.
Ведь тогда, в файле, допустим, /src/index.html необходимо было бы прописывать пути к компонентам, установленным с помощью bower ручками…

Еще немного времени проведенного за поисками привели меня к пакету gulp-wiredep
Тут уже приятней, просто вставив в нужное место следующий код

<!-- bower:css -->
<!-- endbower -->

и выполнив задачу с wiredep на выходе получается, например

<link rel="stylesheet" href="../bower_components/font-awesome/css/font-awesome.min.css" />

Но меня смущает путь к файлу ../bower_compontents/bla-bla-bla/etc. Смущает тем, что bower_compontens находится вне папки dist, все-таки, хотелось бы чтобы после сборки, все необходимые файлы лежали в /dist и не было возни с путями.

И еще немного погуглив нашел компонент gulp-useref. С его помощью, все подключенные файлы внутри следующих комментариев:

<!-- build:css css/vendor.css-->
<!-- include css files here -->
<!-- endbuild -->

будут объеденены в один файл vendor.css и помещены в папку css

Итак, к чему я пришел.
1. main-bower-files копирует основные файлы компонента в, например, /dist/assets/font-awesome
2. wiredep прописывает пути к основным файлам компонента в html файл
3. useref объеденяет файлы и прописывает путь в html к сгенерированому файлу

Но и тут не все так гладко… После того, как useref объеденит файлы, пути внутри этих файлов становятся не валидными. Например, после

<!-- build:css css/vendor.css-->
<link rel="stylesheet" href="../bower_components/font-awesome/css/font-awesome.min.css" />
<!-- endbuild -->

В папке /dist/css будет находится файл vendor.css, в котором пути до шрифтов будут выглядеть следующим образом:

@font-face{font-family:'FontAwesome';src:url('../fonts/fontawesome-webfont.eot?v=4.6.3')...

Хотя шрифты, в действительности, будут находится в /dist/assets/font-awesome/fonts или на худой случай в ../bower_components/font-awesome/fonts

В общем, никак не могу найти правильное решение этой задачи. Хотелось бы и чтобы пути в html автоматически прописывались, и файлы конкатенировались, и в папке dist мусора не было.

Буду рад любым подсазкам и любой помощи.

На данный момент структура проекта выглядит так:

Приношу свои извинения за возможную избыточность в объяснениях и за количество текста.
Заранее спасибо