Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Overrides #585

paulmillr opened this Issue · 16 comments

Here’s a deal.

Some bower packages don’t have bower.json. Or component.json. For example, backbone. Sure, bower.json is generated automatically after clone.

On the other hand, there are automatic builders. I’m building one. I don’t want to specify which files exactly I want to use, really. So, i’ve made a thing that automatically calculates order for packages. If Chaplin depends on Backbone and Backbone depends on Underscore, the order will be [underscore, backbone, chaplin].

The thing is, it requires dependencies and concatenator requires a list of files (main, scripts or styles).

I have solved this effectively by specifying overrides property in bower.json.

If Chaplin has this in bower.json

  "overrides": {
    "backbone": {
      "dependencies": {
        "lodash": "*"
      "main": "backbone.js"

my builder will automatically insert it to backbone’s bower.json, simple as that.

So, my proposition is just to standardise this practice. In the past I was lobbying for mandatory main field, but this does not seem to be possible since some package maintainers (jashkenas) are conservative about including bower.json.


+1 for this. I can work on a PR if people think this is a good idea.


This goes well with a requested feature in #702 because the same property could serve the two purposes.
This needs discussion, @paulmillr feel free to join us on weekly meetings at #bower IRC channel monday 22h30 pm GMT0


ok then


+1 here to, this would make things a lot cleaner for us as we're generating require.js package definitions from this.


+1 this is useful to use with grunt-bower-install


I have a working in production software that automatically gathers all bower files in correct order with these overrides and already uses it since July. Works like a charm.

@paulmillr paulmillr referenced this issue from a commit in paulmillr/ostio
@paulmillr paulmillr Switch to Exoskeleton from Backbone. Drop jQuery & underscore.
* Dropped jQuery and underscore dependencies.
* Added Davy for promises.
* Exoskeleton is a no-deps backbone fork

See bower.json for the main change you will need to do.

+1 - would love to have it :) and I use grunt-bower-install too.


I don't like it, but it does temporary solve a big problem with the registry being a total mess.
So a reluctant :+1: from me.


:+1: been using this with Brunch for quite awhile. Very handy.


:+1: Would also be really handy if you could substitute the origin of a dependency through this. For example, if you had your own custom build of jQuery and a package would depend on jQuery, Bower would then use the version you provide instead of trying to use the official jQuery package from the registry.


:+1: Considering a number of tools that are built on top of Bower have already implemented this in various incarnations, having it in core would standardize the behaviour and ensure consistency.


The path to getting this in is to get a commit through on the bower.json spec repo.

@JeroMiya JeroMiya referenced this issue from a commit in JeroMiya/bower.json-spec
@JeroMiya JeroMiya Added proposed 'override' option.
This is the proposed change to the spec described in bower/bower#585 with one addition - the ability to specify a path to a .json file instead of an inline object literal value to override, and the option to either replace the dependency's original bower.json value or merge with the original.
@JeroMiya JeroMiya referenced this issue in bower/bower.json-spec

Added proposed 'override' option. #27


Another use case for this feature: as a way to implement multi-component bower repositories. For instance, this repository:

already has a workflow for aggregating multiple components (TypeScript typings for various other javascript libraries) into one repository. However, this makes bower integration impossible without splitting up the original repository into separate repositories for each typescript typing, which is too much overhead for this particular project. With bower.json overrides implemented, one could reference the same git repository multiple times in your component's bower.json, and override the excluded files for each reference to only include the files for the component you're interested in (e.g. the angular typings), with different revisions for each reference.

That being said, the proper solution to multi-component git repositories would be to implement that feature explicitly, perhaps through a new dependency referencing syntax to specify the subdirectory within the git repository to work with instead of the root.


This could also provide a temporary work-around for the issue I opened (#1252) because the registry is such an unreliable mess, at the moment (like @sindresorhus also suggests). The ideal case would be to force authors to include a bower.json, but this feature would allow good citizens to patch the holes.

The hazard with this feature is that devs could unknowingly install two packages that both override the same third-party package, no? I guess it depends on how tools use this feature.


Only one bower.json value would be used per dependency, and the value would be determined recursively:
If you define an override, your override takes precedence over any overrides your dependencies have. If your bower.json lists a dependency as a direct dependency without an override, then any transitive overrides of your component's dependencies are ignored/reset. Multiple overrides within a set of peer dependencies are evaluated in the order they appear in bower.json. Non-replacing overrides are cumulative, given the order implied above.


Discussion moved to bower/bower.json-spec#27

@sheerun sheerun closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.