Beginners Guide: Getting Started with Bower Package Manager

Published Nov 03, 2014Last updated Aug 04, 2017

Bower is a front-end package manager built by Twitter. Also known as a Package manager for the Web, bower is used in modern open source and closed source projects to solve many recurrent issues.

This article will guide you through basic bower usage and advanced usage for a team environment. I will also share my personal workflow when dealing with bower with a team of developers.

Problems that bower solves

Developing a website or web application nowadays requires the usage of many front-end frameworks, such as Bootstrap, jQuery, Angular, etc.

  1. Downloading each one of these packages requires navigating the corresponding website, finding the appropriate version, downloading it, unzipping and finally moving the mainfiles to the vendor folder. (e.g.: the main file in in jquery package is jquery.js)
  2. After having the files downloaded in your repository, you have to manually visit all the above websites (,, to check for updates and guess what? If there is an update, you have to repeat step 1 for each package/update.
  3. Let’s assume we’re going to use Bootstrap which requires jQuery (called dependency). When you go to to downoad it, you will then have to navigate to to download jquery as well.

In summary, bower helps you manage your front-end packages. It helps you download them, update them and resolve their dependencies.

There are other benefits of using bower that we will discuss later in this article, but these are the main issues that bower is solving for us!

Installation and usage

Installing bower

Bower is a node module, and can be installed with the following command:

npm install -g bower

This will install bower globally on your system.

If you don’t have node installed on your computer, you have to download it from

Installing packages

For the sake of this tutorial, we’ll use bower to install bootstrap. The process will work for any other package.

bower install bootstrap

This will install bootstrap in the newly created /bower_components folder (at the root level).

Note that this is going to install bootstrap 3.2.x which is the latest version at the time of writing this article. If we want to install the latest version in 2.x, we need to run:

bower install bootstrap#2

we can also specify the exact version with

bower install bootstrap#2.2

Also note that because bootstrap depends on jQuery, running any of the previous commands will automatically install jQuery as well, in order to resolve bootstrap’s dependencies.

Updating packages

If we want to update all our packages, we just need to run the following command:

bower update

Including scripts

The last step would be to include the downloaded styles and scripts. Since they all reside inside the /bower_components folder, we’ll have to write the following:

<link rel="stylesheet" type="text/css" ref="bower_components/bootstrap/dist/css/bootstrap.css">

<script src="bower_components/jquery/dist/jquery.js"></script>

<script src="bower_components/jquery/dist/js/bootstrap.js"></script>

Common workflow in a team environment

After using bower in the above minimalistic way, we realize that it introduces new issues when working with source control and/or in a team environment.

  1. Bower not only downloads main distribution files, but it also downloads the whole repository of jquery, bootstrap, etc. This can bloat your revision control history and is totally not recommended.
  2. Also main distribution files (dist/jquery.js, dist/css/bootstrap.css) are not minified, and bower will never minify distribution files because it is a package manager, not a build tool.
  3. You have to manually make sure to load jquery before loading bootstrap (because bootstrap has jquery as a dependency).
  4. You have to manually add a new <script> tag for every new package (and maybe a new <link rel=”stylesheet”/> if it contains css files.

Step 1: Install bower

and make sure every person in your team installs it globally as well.

Step 2: Exclude bower_components from revision control

Add bower_components to your .gitignore. This will instruct Git to ignore all the bower_components file. In that way each developer (in a team) will have a local copy of the required front-end libraries. Don’t worry about each developer having a different version. We’ll fix that in a few.

Step 3: Install the required packages

Install the required front-end packages, let’s say jQuery and bootstrap.

bower install jquery#1 bootstrap --save

The --save flag will instruct bower to create (if it does not exist) a bower.json file and include the installed packages in it. This is an example of the generated bower.json file:


  "name": "package name",

  "version": "2.9.0",

  "private": true,

  "dependencies": {

    "bootstrap": "~3.2.0",

    "jquery": "1",



notice how there is a version constraint ~3.2.0. This will ensure that all of the team members will be working on the same version of bootstrap, tilde means that the reason should be reasonably close to the specified reason.

Step 4: Team members can now run: bower install

When any developer who has access to the repository runs bower install, it installs all the dependencies (bootstrap and jquery in this case).

For the remaining steps, we need Grunt or Gulp.

Step 5: Integrate with Build tools

Grunt and Gulp are build tools, used to automate common and recurrent tasks, such as minifying scripts, optimizing images, minifying stylesheets, compiling less/sass/stylus. Bower plays well with Grunt/Gulp because of ready made plugins. In this tutorial I am going to cover Grunt, however you will find a similar alternative for Gulp.

Grunt has a plugin called grunt-bower-concat which compiles all the main files for each bower component you have into a bower.js file. Which you can then use Grunt to minify (uglify), resulting in bower.min.js.

Grunt bower concat sample configuration:

        all: {
                dest: "src/js/vendor/bower.js",
                destCss: “src/css/vendor/bower.css”

Note: if you’re using Gulp, a similar plugin exists at:

Note: For Ruby on Rails and others, check the following link:

Step 6: Include scripts

With the following scripts, you include your scripts once and whenever you add a new front-end package, it will be automatically concatenated in the corresponding file (bower.css or bower.js)

<link rel="stylesheet" type="text/css" ref="src/css/vendor/bower.css">

<script src="src/js/vendor/bower.js"></script>

Step 7: More bower automation

You can further automate bower. Let’s say you’re working in a team and you add a new bower component (bower install typeahead.js). You don’t want to email everyone telling them to run bower install. We can automate it with grunt-watch and grunt-exec:

watch: {
        less: {
                files: [ 'bower.json' ],
                tasks: [ ‘exec:bower_install' ]
exec: {
        bower_install: {
                cmd: “bower install”

What’s happening here, is that whenever you edit the bower.json file, grunt automatically runs the bower install command. When you commit your changes, and your co-worker pulls your code, grunt-watch will detect a change in bower.json which will then automatically run the bower install command.

How I customize bower in my own workflow

When it comes to package managers, I use a lot of them in my workflow. I use npm to manage grunt and its plugins. Composer to manage my PHP vendor libraries, bower to manage my front-end packages and finally ruby gems to manage Capistrano (a package that is used to automate deployments).

I decided that I want npm to be the main package manager. So I started wrapping all the main commands inside my package.json’s script section. For example:

  • npm run migrate: migrates the database and generate migration files (PHP specific)
  • npm test: runs unit tests
  • npm run protractor: runs end-2-end tests
  • npm run deploy-staging: deploys code to staging machines
  • npm run deploy-production: deploys code to production machines
  • npm start: runs npm install (pre-start), bower update (post-install) and finally grunt

Here’s what’s happening behind the scenes. Consider the following package.json file:


  "name": "test project",

  "version": "2.9.0",

  "private": true,

  "devDependencies": {

    "bower": "^1.3.9",

    "grunt-bower-concat": "^0.4.0",

    "grunt-contrib-uglify": "^0.5.1",

    "grunt-contrib-watch": "^0.6.1",

    "grunt-exec": "^0.4.6",


  "scripts": {

   "prestart": "npm install",

    "postinstall": "bower update --unsafe-perm",

    "start": "grunt"



If you look at the scripts section, you will see that prestart: we run npm install. Because the package.json is included in our repository, if someone adds a new devDependency we need to be able to install the same version easily. (Note that pre start is the first command triggered when you run npm start).

post install (which is triggered by npm install), runs the following command: bower update --unsafe-perm(the --unsafe-perm was only added because bower-update was failing on a Mac). This will keep all our front-end packages up to date.

start:and finally the command start runs grunt.

With this set up, whenever any developer from your team wants to start working on the project, he simply navigates to the project directory and runs npm start to begin working right away.

Using this approach is very effective because you can include other scripts to run from npm, like npm run migrate, npm run deploy-staging, etc.

Using this approach, we are not only encouraging Command Line Usage and automation, we are actually making it uniform.

You can see that we binded npm install with bower update. You can take this a step further and bind all your other package managers with npm install. In such case, running npm install would run all the following commands:

  • bower update
  • composer update --no-dev
  • gem update

Wrapping it up

Bower is an amazing tool that solves fundamental issues with modern web applications. All people are encouraged to use it (and even the new Visual Studio ships with Bower and Grunt/Gulp nowadays).

It can be easily set up when solo developing, however if you’re working in a team, you need to do follow the steps presented in this article to ensure a smooth workflow between all developers in the team.

Discover and read more posts from Jad Joubran
get started