• You start with a project
• 
• You want to use some libraries (Bootstrap, Backbone)
• These libraries have dependencies (jQuery, Underscore)
• These dependencies might have dependencies (Sizzle, etc.)
• ... and so on

• Dependencies get committed
• You move along with your project
• Things are going swell

• Backbone gets updated to version 1.x (finally!)
• You update to the latest version with all of its new features
• You run the unit tests (because you did write tests, right?!?)
• Better yet, you load your application (of course in all browsers!)         

• When we updated Backbone, we updated to version 1.1.x
• Backbone 1.1.x relies on Underscore >= 1.5.0
• Our previous version of Backbone relied on Underscore 1.3.2.

• APIs can shift within dependencies that are abstracted away and can (read: WILL) break
• Dependency management is a volatile process!

• Bower (http://bower.io/) is "A package manager for the web"
• It is an attempt to solve dependency management in large-scale JavaScript applications

{  "name": "Earth-shattering HTML5 Web Application",  "version": "0.0.1",  "ignore": ["**/.*", "bower.json", "test"],  "devDependencies": {    "qunit": "~1.14.0"  },  "dependencies": {    "backbone": "~1.1.0",    "bootstrap": "~3.0.0"  }}

• Package name and description - let your users know what you've made!
• Package version - follows Semantic Versioning specifications
• Package license info - important in redistribution
• The main endpoints of your package
• The dependencies of your package
• The development dependencies ("devDependencies") of your package
• Think unit tests, build scripts, etc.
• The files to ignore when installing your package
• Dotfiles, test directories, etc.

• Defining a new or existing library is simple:

 $ bower init

$ bower install jquery --save$ bower install qunit --save-dev

$ bower install jquery#1.11.0 --save

• Packages can live in Git or SVN

                    

• Bower can specify versions as either:
• Tags
• Branches
• Commit IDs
• "latest"
• Bower packages can be in local or remote repositories
• If you do not specify a URL, Bower will try Github first

• You can install dependencies in a directory excluded from VCS
• Semantic Versioning will keep your dependencies linked to a particular version
• You can define versions of nested dependencies
• This is good for isolating build or testing failures
• You can make dependency installation part of your build process
• Sample Makefile:

# Install new dependencies and update existing ones
vendor:
    bower install --no-color && bower update --no-color

# Force bower to fetch packages for each build
clean:
    bower cache clean

• Bower is adaptable to most build environments (anywhere you can run a command, really)

{
  "directory": "vendor",
  "tmp": ".bower-tmp",
  "storage": {
    "packages": ".bower-cache",
    "registry": ".bower-registry"
  }
}

• "[Bower] offers a generic, unopinionated solution to the problem of front-end package management"
• Client-side dependencies still require organization

 

• Client-side dependencies may still require configuration

• Bower is really only as smart as your VCS!
• Understand tags, branches, and what you are committing
• Try committing compiled resources in tags only

• Bower is a simplistic, yet very useful approach to client-side dependency management
• Building projects with Bower is relatively easy
• Organizing code in projects built using Bower is left largely to the developer

ANY QUESTIONS?