Added proposed 'override' option.

[JeroMiya]

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.

[sheerun]

overrides would be better then override (like dependencies). It would be a compatible naming with grunt-wiredep for example.

I'm not sure about this feature to be specified in bower.json. What if dependency you override is used by other package in project? I think putting this .bowerrc would be safer.

I'd love if override option could also point to repo with overrides. We could create bower/overrides repository maintained by community that defines common overrides. One could fork it of course.

{
  "overrides": "https://github.com/bower/overrides#1.2.3"
}

I guess hash syntax is OK too.

ping @sindresorhus @benschwarz @satazor

[unscriptable]

A bower/overrides repo sounds interesting at first, but I wonder if it's better to just coerce the authors of the components to fix or add bower.json files to their repos? Thoughts @sheerun ?

overrides at the application level makes a lot of sense to me. If an app's use case requires that a particular component behave differently, the app dev can change it locally.

Placing these overrides in .bowerrc seems like a natural choice, but that won't work for our needs in RaveJS/rave since we need to access the overrides from a browser (and most web servers block hidden files by default). If this is the place that you choose, then we'll find a work-around, I guess. :)

This is probably a long shot, but does this sound interesting?

bower override underscore="path/to/my/underscore/override.json"

[sheerun]

@unscriptable It is not that easy to persuade authors to maintain their bower.json. I think we could encourage authors to copy fixed bower.json from bower/overrides to their repositories, and remove overrides from global repo if they do so. It would be easier for both them and for community.

Bower would take overrides from .bowerrc and put them in .bower.json files (bower.json is created by authors, .bower.json by bower), so it would be available in browser.

[sheerun]

Also most authors won't edit old tags in their repositories, so global override is practically the only way to fix old releases of bower components (see for example tenex/rails-assets#124 (comment))

[brunowego]

👍

[sapegin]

👍

[sheerun]

My override format proposal (e.g. jquery.json):

{
  "0.0.0": {
    "description": "Hello world",
    "keywords": [ "jquery", "javascript", "library" ],
    "license": "MIT",
    "ignore": [
      "**/.*",
      "build",
      "speed",
      "test",
    ],
    "main": "jquery.js"
  },
  "0.4.0": {
    "main": "build/jquery.js"
  },
  "master": {
    "main": "dist/jquery.js"
  }
}

It means since version 0.0.0 jquery had main jquery.js, but changed its location in 0.4.0 to build/jquery.js. In master branch the name is dist/jquery.js.

Any suggestions or comments?

[mnquintana]

👍

Most of my thoughts can be found in #38, but I personally like the approach taken by the gulp plugin main-bower-files for package consumers:

{
    "name": "your-package-name",
    "dependencies": {
        "<bower-package>": "*"
    },
    "overrides": {
        "<bower-package>": {
          "main": "some-file.js"
        }
    }
}

Or, NODE_ENV specific overrides:

{
    "overrides": {
        "<bower-package>": {
            "main": {
                "development": "file.js",
                "production": "file.min.js",
            }
        }
    }
}

"main" here would also be able to accept a glob.

---

@sheerun How would that overrides format translate to package consumers?

[sheerun]

I think we could standardize "overrides" entry in same format as wiredep or main-bower-files, and make note that current bower version doesn't implement this field yet, so you need to use external tool.

I think these plugins are proof that community really needs this field.

@sindresorhus I'd urge you to merge this PR.

[sheerun]

I'm only not sure if we should standardize the "replace" and "path to bower.json" behavior.

[sindresorhus]

@sheerun I won't merge this as I think it's a bad idea.

Though this is really up to you, so feel free to merge if you think it's a good idea. I'm not really much involved anymore.

[mnquintana]

@sindresorhus Just out of curiosity, why do you think it's a bad idea?

[sindresorhus]

@mnquintana It's in multiple old issues. I have no interest in discussing this further :)

It's up to @sheerun now.

[Yeti-or]

@sheerun any hope here?

[sheerun]

I need to find and read those multiple old issues first. Maybe you can help.

Also, maybe it would be better to implement overrides on registry level for consistency. That is, allow for specifying custom registry where all overrides are stored.

[CWSpear]

It would be great if there was some sort of spec on the matter, as a lot of people have already started implementing their own thing to great success (such as the mentioned wiredep and grunt-bower-files), but without a spec to go off, people start implementing their own thing and pieces no longer work in harmony. Not for lack of wanting to be harmonious, but for a lack of a unified spec.

For example, wiredep is considering adding glob support for their overrides: taptapship/wiredep#144

Which is great and dandy until another tool chooses not to do it that way, there's fragmentation.

I've seen other tools use bowerOverrides and other things other than overrides for the name.

Then there's the discussion of what should it override? The main property is a popular one, so is dependencies. But what else? What shouldn't be allowed? What should the syntax be?

If Bower remains silent on this, everyone in their community does their own thing. The community is obviously very much behind this idea as it's in use all over. At this point, we need to figure out how we can all come to a compromise, as it's much easier to say, "we should do it this way because Bower (the source) recommends it this way," than to say, "well, I feel it should be done this way, and there's not even an 'unofficial' spec to go off of, so why shouldn't I?"

[stevemao]

Updates on this one?

[joelataylor]

I was looking for this documentation - is there a reason it hasn't been merged yet? Also, it would be great to include an example! Thanks.

[sbley]

Any news on this?

[sheerun]

Yes, it's not needed anymore, because override option can be implemented by Pluggable Resolver. Unfortunately it won't be implemented by Bower itself (we can incorporate resolver in 2.0 version, though).

Also, I'm thinking of "Pluggable Postprocessors" in addition to Pluggable Resolvers: bower/bower#1930