Bower is a package manager for frontend web assets and libraries. You will use it to maintain your frontend stack and control version chains for libraries such as jQuery, AngularJS, and any other components necessary to your app's web interface.
Bower is also a Node.js package, so you will install it using NPM, much like you did with the Browserify example installation in the previous section, but this time you will be installing the package globally. This will allow you to run bower from the command line anywhere on your system without having to install it locally for each project:
$ npm install -g bower
You can alternatively install Bower locally as a development dependency so that you may maintain different versions of it for different projects on the same system, but this is generally not necessary:
$ npm install bower --save-dev
Next, check that Bower is properly installed by querying the version from the command line:
$ bower -v
Bower also requires a Git version control system, or VCS, to be installed on your system in order to work with packages. This is because Bower communicates directly with GitHub for package management data. If you do not have Git installed on your system, you can find instructions for Linux, Mac, and Windows at git-scm.com.
The process of setting up your bower.json file is comparable to that of the package.json file for NPM. It uses the same JSON format, has both dependencies and devDependencies, and can also be automatically created:
$ bower init
Once you type bower init from the command line, you will be prompted to define several properties with some defaults given within parentheses:
? name: my-app ? version: 0.0.0 ? description: My app description. ? main file: index.html ? what types of modules does this package expose? (Press <space> to? what types of modules does this package expose? globals ? keywords: my, app, keywords ? authors: Philip Klauzinski ? license: MIT ? homepage: http://gui.ninja ? set currently installed components as dependencies? No ? add commonly ignored files to ignore list? Yes ? would you like to mark this package as private which prevents it from being accidentally published to the registry? Yes
Most properties in the bower.json file are not necessary unless you are publishing your project to the Bower registry, indicated in the final prompt. You will most likely want to mark your package as private, unless you plan to register it and allow others to download it as a Bower package.
Once you have created the bower.json file, you can open it in a text editor and change or remove any properties you wish. It should look something like the following example:
{
"name": "my-app",
"version": "0.0.0",
"authors": [
"Philip Klauzinski"
],
"description": "My app description.",
"main": "index.html",
"moduleType": [
"globals"
],
"keywords": [
"my",
"app",
"keywords"
],
"license": "MIT",
"homepage": "http://gui.ninja",
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"
],
"private": true
}
If you wish to keep your project private, you can reduce your bower.json file to two properties before continuing:
{
"name": "my-app",
"private": true
}
Once you have the initial version of your bower.json file set up the way you like it, you can begin installing components for your app.
Bower will install components into a directory named bower_components by default. This directory will be located directly under the root of your project. If you wish to install your Bower components under a different directory name, you must create a local system file named .bowerrc and define the custom directory name there:
{
"directory": "path/to/my_components"
}
An object with only a single directory property name is all that is necessary to define a custom location for your Bower components. There are many other properties that can be configured within a .bowerrc file. For more information on configuring Bower, see bower.io/docs/config/.
Bower also allows you to define both the dependencies and devDependencies objects like NPM. The distinction with Bower, however, is that the dependencies object will contain the components necessary for running your app, while the devDependencies object is reserved for components that you might use for testing, transpiling, or anything that does not need to be included in your frontend stack.
Bower packages are managed using the bower command from the CLI. This is a user command, so it does not require super user (sudo) permissions. Let's begin by installing jQuery as a frontend dependency for your app:
$ bower install jquery --save
The --save option on the command line will save the package and version number to the dependencies object in bower.json. Alternatively, you can use the -S option as a shortcut for --save:
$ bower install jquery -S
Next, let's install the Mocha JavaScript testing framework as a development dependency:
$ bower install mocha --save-dev
In this case, we will use --save-dev on the command line to save the package to the devDependencies object instead. Your bower.json file should now look similar to the following example:
{
"name": "my-app",
"private": true,
"dependencies": {
"jquery": "~2.1.4"
},
"devDependencies": {
"mocha": "~2.3.4"
}
}
Alternatively, you can use the -D option as a shortcut for --save-dev:
$ bower install mocha -D
You will notice that the package version numbers are preceded by the tilde (~) symbol by default, in contrast to the caret (^) symbol as is the case with NPM. The tilde serves as a more stringent guard against package version updates. With a MAJOR.MINOR.PATCH version number, running bower update will only update to the latest patch version. If a version number is composed of only the major and minor versions, bower update will update the package to the latest minor version.
All registered Bower components are indexed and searchable through the command line. If you don't know the exact package name of a component you wish to install, you can perform a search to retrieve a list of matching names.
Most components will have a list of keywords in their bower.json file so that you can more easily find the package without knowing the exact name. For example, you may want to install PhantomJS for headless browser testing:
$ bower search phantomjs
The list returned will include any package with phantomjs in the package name or within its keywords list:
phantom git://github.com/ariya/phantomjs.git dt-phantomjs git://github.com/keesey/dt-phantomjs qunit-phantomjs-runner git://github.com/jonkemp/... parse-cookie-phantomjs git://github.com/sindresorhus/... highcharts-phantomjs git://github.com/pesla/highcharts-phantomjs.git mocha-phantomjs git://github.com/metaskills/mocha-phantomjs.git purescript-phantomjs git://github.com/cxfreeio/purescript-phantomjs.git
You can see from the returned list that the correct package name for PhantomJS is in fact phantom and not phantomjs. You can then proceed to install the package now that you know the correct name:
$ bower install phantom --save-dev
Now you have Bower installed and know how to manage your frontend web components and development tools, but how do you integrate them into your SPA? This is where Grunt comes in.