Command line reference


$ bower cache <command> [<args>]

Manage bower cache

cache clean

$ bower cache clean
$ bower cache clean <name> [<name> ...]
$ bower cache clean <name>#<version> [<name>#<version> ..]

Cleans cached packages

cache list

$ bower cache list
$ bower cache list <name> [<name> ...]

Lists cached packages


$ bower help <command>

Display help information about Bower


$ bower home
$ bower home <package>
$ bower home <package>#<version>

Opens a package homepage into your favorite browser.

If no <package> is passed, opens the homepage of the local package.


$ bower info <package>
$ bower info <package> [<property>]
$ bower info <package>#<version> [<property>]

Displays overall information of a package or of a particular version.


$ bower init

Interactively create a bower.json file


$ bower install [<options>]
$ bower install <endpoint> [<endpoint> ..] [<options>]

Installs the project dependencies or a specific set of endpoints.

Endpoints can have multiple forms:

  • <package>
  • <package>#<version>
  • <name>=<package>#<version>


  • <package> is a package URL, physical location or registry name
  • <version> is a valid range, commit, branch, etc.
  • <name> is the name it should have locally.

<package> can be any one of the following:

Registered package name jquery
Git endpoint https://github.com/user/package.git
Git endpoint without .git git+https://github.com/user/package
Local folder my/local/folder/
Public Subversion endpoint svn+http://package.googlecode.com/svn/
Private Subversion endpoint svn+ssh://package.googlecode.com/svn/
Shorthand (defaults to GitHub) user/package
URL http://example.com/script.js
http://example.com/package.zip (contents will be extracted)
http://example.com/package.tar (contents will be extracted)

A version can be:

semver version #1.2.3
version range #1.2
#>=1.2.3 <2.0
Git tag #<tag>
Git commit SHA #<sha>
Git branch #<branch>
Subversion revision #<revision>

install options

  • -F, --force-latest: Force latest version on conflict
  • -p, --production: Do not install project devDependencies
  • -S, --save: Save installed packages into the project’s bower.json dependencies
  • -D, --save-dev: Save installed packages into the project’s bower.json devDependencies
$ bower link
$ bower link <name> [<local name>]

The link functionality allows developers to easily test their packages. Linking is a two-step process.

Using ‘bower link’ in a project folder will create a global link. Then, in some other package, bower link <name> will create a link in the components folder pointing to the previously created link.

This allows to easily test a package because changes will be reflected immediately. When the link is no longer necessary, simply remove it with bower uninstall <name>.


$ bower list [<options>]

List local packages and possible updates.

list options

  • -p, --paths: Generates a simple JSON source mapping
  • -r, --relative: Make paths relative to the directory config property, which defaults to bower_components


$ bower lookup <name>

Look up a package URL by name


$ bower prune

Uninstalls local extraneous packages


$ bower register <name> <url>

Register a package

$ bower search
$ bower search <name>

Finds all packages or a specific package.


$ bower update <name> [<name> ..] [<options>]

Updates installed packages to their newest version according to bower.json.

update options

  • -F, --force-latest: Force latest version on conflict
  • -p, --production: Do not install project devDependencies


$ bower uninstall <name> [<name> ..] [<options>]

Uninstalls a package locally from your bower_components directory

uninstall options

  • -S, --save: Remove uninstalled packages from the project’s bower.json dependencies
  • -D, --save-dev: Remove uninstalled packages from the project’s bower.json devDependencies


$ bower version [<newversion> | major | minor | patch]

Run this in a package directory to bump the version and write the new data back to the bower.json file.

The newversion argument should be a valid semver string, or a valid second argument to semver.inc (one of “build”, “patch”, “minor”, or “major”). In the second case, the existing version will be incremented by 1 in the specified field.

If run in a git repo, it will also create a version commit and tag, and fail if the repo is not clean.

version options

  • -m, --message: Custom git commit and tag message

If supplied with --message (shorthand: -m) config option, bower will use it as a commit message when creating a version commit. If the message config contains %s then that will be replaced with the resulting version number. For example:

$ bower version patch -m "Upgrade to %s for reasons"



-f, --force

Makes various commands more forceful


-j, --json

Output consumable JSON


-l, --log-level

What level of logs to report


-o, --offline

Do not use network connection


-q, --quiet

Only output important information


-s, --silent

Do not output anything, besides errors


-V, --verbose

Makes output more verbose



Allows running commands as root. Bower is a user command, there is no need to execute it with superuser permissions. However, if you still want to run commands with sudo, use --allow-root option.

Consuming a package

Bower makes available source mapping. This can be used by build tools to easily consume Bower packages.

If you use bower list --paths or bower list --paths --json, you will get a simple name-to-path mapping:

$ bower list --paths
# or
$ bower list --paths --json
  "backbone": "bower_components/backbone/backbone.js",
  "jquery": "bower_components/jquery/dist/jquery.js",
  "underscore": "bower_components/underscore/underscore.js"

Every command supports the --json option that makes Bower output JSON. Command result is outputted to stdout and error/logs to stderr.

Programmatic API

Bower provides a powerful, programmatic API. All commands can be accessed through the bower.commands object.

var bower = require('bower');

.install(['jquery'], { save: true }, { /* custom config */ })
.on('end', function (installed) {

.search('jquery', {})
.on('end', function (results) {

Commands emit four types of events: log, prompt, end, error.

  • log is emitted to report the state/progress of the command.
  • prompt is emitted whenever the user needs to be prompted.
  • error will only be emitted if something goes wrong.
  • end is emitted when the command successfully ends.

For a better idea of how this works, you may want to check out our bin file.

When using bower programmatically, prompting is disabled by default. Though you can enable it when calling commands with interactive: true in the config. This requires you to listen for the prompt event and handle the prompting yourself. The easiest way is to use the inquirer npm module like so:

var inquirer =  require('inquirer');

.install(['jquery'], { save: true }, { interactive: true })
// ..
.on('prompt', function (prompts, callback) {
    inquirer.prompt(prompts, callback);

Running on a continuous integration server

Bower will skip some interactive and analytics operations if it finds a CI environmental variable set to true. You will find that the CI variable is already set for you on many continuous integration servers, e.g., CircleCI and Travis-CI.

You may try to set the CI variable manually before running your Bower commands. On Mac or Linux, export CI=true and on Windows set CI=true

If for some reason you are unable to set the CI environment variable, you can alternately use the --config.interactive=false flag.

$ bower install --config.interactive=false

Using local cache

Bower supports installing packages from its local cache – without internet connection – if the packages were installed before.

$ bower install <package> --offline

The content of the cache can be listed with bower cache list:

$ bower cache list

The cache can be cleaned with bower cache clean:

$ bower cache clean