Ability to include a property or list of properties in your own bower.js...

[WaleedTayeb]

... file.

This may be used in case you do not wish to override a package's bower.js main property, but simply include other files (such as themes) with it.

[ebbe-brandstrup]

+1. I've been looking for something like this! Would like to see that merged, please.

[CWSpear]

How does this different from overrides?

[CWSpear]

Ok, I think you edited your original note after my last comment.

So basically, you want overrides-like functionality, but you want it to merge in the main, etc, instead of replacing it?

[ebbe-brandstrup]

The value I see in the merge vs. override is that merging means I'm messing less with the internals of the 3rd party component - only adding an optional dependency.

That way the 3rd party component is still free to restructure / rename internally without breaking stuff.

[stephenplusplus]

Like in so many feature requests lately, I see both sides of this. In some ways, I want to just support it, 'cause why not. But, it's also really just giving developers a way to get into trouble, and have things just stop working one day, without a clue as to what broke.

That way the 3rd party component is still free to restructure / rename internally without breaking stuff.

This is exactly the problem. When a package you know better than* makes changes to its structure, you need to be aware of the changes upstream before incorporating it into your project.

* know better than: By using "overrides" or the proposed "include", you are using the package outside the scope of its original intentions. You either need more, less, or something completely different from it.

I'm currently on the side of not supporting this, but please continue to discuss.

[CWSpear]

I'm actually not really in favor of this either, as I've come up against similar situations and handled it fine with the current overrides.

But I want to point out it's not always about "using the package outside the scope of its original intentions." It's more and more common for these 3rd party packages to offer theming options and stuff, and they just put a base theme in the main, and you'd need something like overrides to include a different theme (the themes (apart from the base) are mutually exclusive). I've seen stuff like this a few times.

But, I think overrides is still better for this because it gives you control of that order (maybe, for some reason, the base styles need to be included before or after the theme. This new proposal doesn't give you control over that, while the existing overrides does).

As an example, here's a snippet from a project I'm currently working on (with comments, which normally aren't allowed in bower.json):

"overrides": {
  "ladda": {
    "main": [
      "./dist/ladda.min.js",
      // ladda includes a compiled CSS file with its own theme by default. I don't 
      // want to merge with that, I want to replace it complete with the themeless CSS
      "./dist/ladda-themeless.min.css"
    ]
  },
  "jquery-ui": {
    "main": [
      // jquery-ui only has one main file: the fully compiled jquery-ui.js
      // but I only want the datepicker (which from their site, I 
      // learned only depends on the core)
      "./ui/core.js",
      "./ui/datepicker.js",

      // jquery-ui does not include *any* css by default, but 
      // I want the datepicker styles and the dark-hive theme.

      // This *could* be a use-case for `include`s, but it can still be handled 
      // by overrides anyway, which I need for the other use-cases above 
      "./themes/base/datepicker.css",
      "./themes/dark-hive/theme.css"
    ]
  }
},

[stephenplusplus]

+1.

It would be great if those packages that offer themes or plug-ins would release them independently as their own package.

[WaleedTayeb]

I agree that the best solution would be to have these third party packages released their themes as their own package. However, it would be rather painful to ask every author of those packages to do so. Some of them don't even release their packages already built (with grunt).

It was not my intention in my proposal to replace the override function, just another way of including files not originally included by the author of the 3rd party component. Both these functions introduce a risk of things breaking software. It is therefore the job of the developer to recognize that using there functions introduces a risk.

[stephenplusplus]

Thanks for putting this together @WaleedTayeb. I see your point, but don't want to support this behavior in wiredep for the reasons I mentioned above. :v: