Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Adding support for specifying bower configuration in package.json #62

wants to merge 1 commit into


None yet

iros commented Sep 17, 2012

Adding another json configuration file might seem like too many configuration files for some (especially if custom projects already have their own and that cannot be changed.)

This patch supports adding the bower configuration in package.json under the bower property like so:

  "name": "other",
  "description": "Another thing",
  "version": "0.1.5",
  "bower" : {
    "name": "myproject",
    "version": "1.5.23",
    "dependencies": {
      "package-bootstrap": "git://github.com/fat/package-bootstrap.git#~2.0.0",
      "jquery": "git://github.com/maccman/package-jquery.git#v1.7.2"

Please consider supporting this feature, especially since the patch is so small.
Test included.


paulirish commented Sep 17, 2012

I don't actually a clear picture on why this didn't work for @fat in the original design. Though I know he feels strongly. We need some docs.

iros commented Sep 17, 2012

It would be good to see a test where this is an issue... I've added a test that passes, but I would be glad to hear why this is a problem. I find adding a component.json file to be an extra cost for projects that involve boilerplates that already tax the user in terms of specifying their project requirements.


addyosmani commented Sep 17, 2012

I think there are already plans underway for the design/spec docs that @paulirish mentioned above. fwiw, I'm all for this. I'd be interested to hear what @visionmedia thinks of the proposal :)

tj commented Sep 17, 2012

I'm taking the stand that I don't care for package.json haha, I'm completely done dealing with old cruft, I'm attempting to ignore it and continue on with what I feel is a better way to handle all this client side stuff. I don't want to waste too much energy supporting legacy ideas, personally.

tj commented Sep 17, 2012

plus a file is a file right? it's not the end of the world, it may not be elegant, but neither is having several nested duplicated descriptions in one file

iros commented Sep 17, 2012

@visionmedia with all due respect, I think your personal preference is not a great reason here. A file is a file, but with that argument you can add 100. Doesn't mean it's a good idea.

If you are aiming for wide bower adoption, then you need to take into account that people already have established projects that make heavy use of package.json. More often than not, we require a package.json for npm packages. Additionally, many projects have been using package.json in the way that I added (by reserving a property under the main object.)

I don't see how supporting this would be any kind of loss to you. The patch is tiny because there is only one entry point.

tj commented Sep 17, 2012

I'm not using bower. The stuff I'm doing is fundamentally different, which helps justify a new file a bit more github.com/component

iros commented Sep 17, 2012

Ah @visionmedia. I was not aware of component. I still think for bower specifically, it would make a lot of sense.

tj commented Sep 17, 2012

bower would only need "bowerDependencies": {} or something no? does it use other values?

iros commented Sep 17, 2012

@visionmedia there is a main property, but I haven't seen it used yet.


fat commented Sep 17, 2012

The main reason I don't like this is there is a lot of ambiguity when you start nesting package specifications like this.

You effectively get the xzibit effect (hey son, i heard you like package configs, so i put a package config inside your package config.)

It's not like the npm config and the bower config are lying next to each other on equal terms.

The ambiguity comes because (as seen in your example) you have two names, two dependencies objects, etc.

This means you have to start to develop more complex rules (if there is no name, do you look up the tree to see if there is another name? Or do you require all the attributes to be duplicated.

We tried to do this with ender, and it lead to a lot of confusion for users… there's no obvious expectation about what is used and when. They have to read the docs, and no one really reads docs. Especially as this project grows.

What i would actually prefer to see is something closer to a config.json - which was supported by the whole ecosystem. Then you could do something like:

  "npm"   : { … contents for npm … },
  "bower" : { … contents for bower … }

might be able to get @isaacs to agree to something like that.

@iros We specified the main property for CanJS as "main": "./can.js", but it's unclear what its used for. Initially I thought it only installed that file when you install via bower install canjs, however it seems to just clone the whole repo.

I would agree with @fat. Obviously not all npm projects should be bower projects and vice versa, and I don't want to have to look two places for a bower component definition.


fat commented Sep 17, 2012

The main file is used as part of an api that bower exposes for thirdparty build systems.

If you run bower ls --map for example you can see the output of what it would be.

iros commented Sep 17, 2012

@fat thanks for clarifying your reservations.

While I agree that an agnostic config.json would be swell, it doesn't exist right now. What does exist are thousands of npm-dependent projects out there with a package.json. Why not support this until a more generic option is supported? For what it's worth, I too +1 the config.json, but I have code to release sooner than that will become available and I'd love to use bower.

Don't assume all users are idiots. I'm a user of your lib and I read through all your docs several times. Maybe users won't at first, but when they get stuck, they will. If your docs are clearly organized, they will find their answer there. I'm not saying everyone does this, but to say that no one does is a bit unfair.

The rule complexity is really not that great here. Have a component.json? No? Have a package.json with a bower property? No? Then you can't install anything. done. What's complicated about that? I'd be glad to contribute the README change for this as well, as I realized I did not do so.

As far as dependency property confusion, while an unfortunate overlap in naming, if someone does not understand that node packages are for server side / dev, and bower packages are for client side, then there's probably a lot of other things that need clarification. Rarely will those intersect anyways.

Why not just use the name inside package.json? Is it really ever going to be different? Same for version. Just because I have to specify them in another file, doesn't mean the overlap is irritating (it is ;)) but that's a different pull request. For now, I'm assuming this is a choice you've made and all I'm asking is to preserve your specification and format choices but in package.json.

tj commented Sep 17, 2012

Keep in mind though node is not some all-consuming thing... just because it's a little bit more convenient for node people to use package.json doesn't mean much to any other community. Something like a config.json would be reasonable, though it's not obvious what's supported until you take a look at the file, that's one reason I like separate files personally, not a huge issue though

geddski commented Sep 17, 2012

I like the single, common config.json. It could become the standard for all current and future JS package managers.

@fat thanks for the clarification wrt main -- in that case we need to update ours.


fat commented Sep 17, 2012

@iros no worries, I'm up for the discussion always…

Why not support this until a more generic option is supported?

Unfortunately the way things tend to work out is if you start supporting something, you will likely end up supporting it for a super long time.

Deprecation is painful - and the benefit of having a "single file" isn't great enough to warrant a bad design (imho).

Don't assume all users are idiots

I would never assume that. I only assume that I'm an idiot. Which I am. I've used NPM for a while now, and I can safely say i've never read through all of its documentation. It's easy now for bower, because the docs are sparse, but as the project matures it'll be more difficult to assume people have read everything.

The rule complexity is really not that great here

Its not that the complexity of this rule is great – it's that the potential for complexity is great. And therefore it is a high learning curve. This potential is illustrated by your last paragraph.

iros commented Sep 17, 2012

I should also add that currently, if no component.json exists, bower defaults to package.json anyway, except it reads node dependencies - which I would argue isn't the right answer. Why would my server/dev dependencies be the same as my client ones?


fat commented Sep 17, 2012

@iros agreed. but this is only true of project dependencies, and was only done to bootstrap the registry (making things like backbone, etc. work out of the box).

It's value as a bootstrapping tool is more clear than namespaced bower packages (which don't exist anywhere).

iros commented Sep 17, 2012

@fat thanks for the thoughtful response.

Why do you foresee supporting a property in package.json in the future a challenge as long as the format underneath it remains consistant with what is in component.json or the possible-future config.json? No custom behavior, no nothing. Just the same format under the bower property?

The npm documentation is probably why you haven't read the npm documentation ;) It's an API doc, not documentation. Plus when you were introducing npm to your dev environment, I bet you sat and read through whatever intro that told you what to do. Same thing with bower - I had to know where to put all my details. If that block said, put them in component.json or under the bower property in package.json, that is all I would need to know.

I would argue that potential for complexity is only as high as we chose to believe it is. I would argue that the complexity is there regardless of the host file and should be addressed separately from this particular concern.

iros commented Sep 17, 2012

@iros agreed. but this is only true of project dependencies, and was only done to bootstrap the registry (making things like backbone, etc. work out of the box).

It's value as a bootstrapping tool is more clear than namespaced bower packages (which don't exist anywhere).

True, but as a result it is in your code and anyone looking at your code will pretty quickly view it as a feature. I know I did. It also explains why projects like d3 were uninstallable until Friday, because they required libraries in the dependencies that were node only. Either way, I didn't take support out for that. If no bower property exist, it will behave as it always did.


maccman commented Sep 17, 2012

Yes, this is definitely something we've thought carefully about and not something we considering for the reasons @fat specified earlier. Sorry about that!

@maccman maccman closed this Sep 17, 2012

tj commented Sep 17, 2012

FWIW if config.json was already a thing and npm used that too I'd +1 that, some common values like name/keywords/description etc make sense at the root level but all others would have made more sense nested, or you end up with compentDependencies, componentDevDependencies, componentBundledDependencies blah blah

iros commented Sep 17, 2012

@maccman your response saddens me. You are ignoring the fact that there is a huge community out there and that you've already made a major decision that depend on it by writing bower as an npm module... Instead of interoperating with other open source software (which is the whole point of writing it in the open) you are picking a reason that is based entirely on your opinion instead of the community needs. I think that is irresponsible to the users and makes me weary about building my software to depend on your conventions (which seem arbitrary and have yet to demonstrate solid technical reasons for your refusal).


fat commented Sep 17, 2012

hmm sorry you feel that way @iros, let me try to explain a bit more…

you've already made a major decision that depend on it by writing bower as an npm module

Bower is implemented in Node because that meant writing it in JavaScript, which is the scripting language of the frontend. And we find that important. I don't think that means we have to privilege peoples projects written in node over projects written in ruby, etc.

For example, bower was developed with Twitter's stack in mind. Twitter is written in ruby, not node.

Instead of interoperating with other open source software you are picking a reason that is based entirely on your opinion instead of the community needs

We actually have held this discussion with a number of major people from a number of communities. The separate file approach is simply the easiest to adopt across stacks (not everyone has a package.json and it doesn't make sense to privilege one package transport over another – doing so very quickly becomes a game of what else should we support? should we add gem support? should we add… it gets very messy, very quick).

seem arbitrary and have yet to demonstrate solid technical reasons for your refusal

this isn't arbitrary. It's based on my direct involvement with the Ender project, which went down this road and lead to headaches. (and even this had a greater tie to NPM and the node network)

It's hard to provide technical reasons against this much in the same way it hard to provide technical reasons for this. It's a trivial change, however it's a bad design.

I'm happy to help push a standard of having a config.json or something which is an aggregate of package definitions for different tools, but I don't want to overload the package.json. There's a clear spec for package.json and as far as I'm aware, there is no mention of nesting package definitions.

I also got the sense that you agree that the config.js is the better solution (though probably not the right "name") – why not use your energy to help push that as a better solution? : )


fat commented Sep 17, 2012

also, out of curiosity - are you wanting this for true packages or because you're using a package.json to install dependencies for your web server project?

Hi all, I don't know if this is a proper place to express this but I find bowers' documentation a bit lacking but more specifically the FAQ is rather vague (the bit where you explain what bower is and why it is what it is).

A few months back when @visionmedia announced his component he did so with a very interesting blog post about web components in general and how he plans to address the subject with component.
Shortly after, @izs and @jrburke posted response blog posts (here and there) expressing their thoughts about web components and package management.

Overall it was a very interesting discussion and I'm certain many people benefitted from reading them. Since then TJ has been committing like mad on components and jam / volo received more exposure.

So when bower came out, I was very excited to see what twitter's developers had come up with, not least because I had used their previous client-side 'modular project' Ender.
I tried bower out on day one and understood all it did was fetch/resolve dependencies, but still I didn't really get the project. I realize now that this is only happening (me getting the project) as I go through all the issues on github. Indeed in has helped me understand a couple of things the docs didn't explain (thanks for clarifying the main property) but more importantly the reasons for the current state of bower. (just read @fat's big comment above this one!)

Now what I really want to say is I think it would help if maybe @fat and @maccman could write a blog post (or something better than the current FAQ!) explaining their motives when creating bower, the reasons behind their main decisions (going for a component.json, only doing package management etc etc) and also where they'd like the project to go since it seems here to stay:

Twitter is in the process of migrating its frontend architecture onto Bower

In other words, something similar to TJ's post. It would probably have more 'reach' than the github issues.

I say that because I follow most of you on twitter and I remember @fat saying this and that at time of writing component and bower are actually VERY different.

tj commented Sep 17, 2012

@athibaud yeah totally different scopes, I'm just sick of writing / using global namespaces and code with a lot of x-browser boilerplate. Something like jQuery makes a lot more sense to be comprised from smaller things that other components can utilize. I still think it's useful to have jQuery-like things, but it could easily be comprised of at least 50+ components, I have 82 public ones already and we have maybe 150 private ones haha and that doesn't even cover all of jquery's stuff yet

geddski commented Sep 17, 2012

@fat just an idea: instead of config.json what if we go with config.js, enabling dynamic settings and comments...

tj commented Sep 17, 2012

@GEDDesign nearly anything out there can read json though, not true for js, so you'd only get extremely minimal benefits from that (even if everyone could consume it)

geddski commented Sep 17, 2012

@visionmedia yeah true.

@visionmedia I completely agree with you, I've been following component's development and I really hope the days of large, tightly-bound monolithic libraries (jQuery :D) are a thing of the past!! (that's kind of Ender's mantra hehe)

What I wanted to say is that at the moment bower seems to be just the component(1) (search/install, not the builder or commonjs require syntax bit) part of component, am I correct? (which actually got me thinking that was cool because them we could swap component(1) for bower and have modular stack but there's the component.json argument ^^).

Like I said in my previous comment, I didn't expect bower to be that, I expected it to be much similar to component. But it seems– from what I've read all over bowers' issue comments–  that @fat and co have put a lot of thought into this (simply being a package manager, not saying that in a bad way) and I'm really interested to know why and how bower integrates in their current stacks (twitters' or personal).

In my ideal world we would have a fully inter-compatible front-end stack. We would write all our code in modes/packages in a standard (say... commonjs :)) and then have:

  • a package manager solving deps and fetching packages (component, volo, bower, jam.. whichever one you prefer)
  • a builder for consumption in the browser (requirejs, component-builder, browserbuild etc etc)

all these would follow the same standard interface and each would have their implementation or specific option, then people can just choose and it will all work haha

tj commented Sep 17, 2012

@athibaud they're not interchangeable because the goals are fundamentally different, so you can't use bower things with component etc. IMO the problem with just being a package manager is that it doesn't really solve a whole lot, it's effectively git submodules. component(1) avoids tarballs and git all-together and is roughly 8x faster than volo / bower, avoiding git clones is well worth it

@visionmedia yup, I had figured all of that out by reading through the docs, wikis and issues.

I agree that simply being a package manager doesn't solve a lot, that's one of the reasons why I was requesting the bower devs to explain their motives and their uses of bower.

There's a lot a choice right now for package managers and such, it can be quite overwhelming and confusing if not properly informed. That's why I was suggesting a blog post thing for bower since it's probably the project with most exposure. Y'all know how it goes, a good old blog post retweet by addy or paul irish and it might even become a trending topic hehe.

isaacs commented Sep 17, 2012

I was summoned via twitter: https://twitter.com/fat/status/247768978603249664

Node and npm are going to keep using package.json exclusively. We're not that interested in messing around with the module system any more.

You're welcome to extend package.json in new systems like bower if it suits you. Or not. Whatever. You can just pretty much treat npm and node's use of package.json as a fact of nature at this point.

I'm confused. What problems does Bower solve that NPM doesn't? @visionmedia, Component seems much more valuable for doing what I think people need to do sane client side programming, but it's guilty as well - is NPM really that slow? How often are we installing these packages anyways? I have to admit it seems disappointing that we need MORE package managers... someone convince me?

tj commented Sep 18, 2012

@jessetane that's not the primary reason for building an alternative, just a nice side-effect. For my use the only reason to use npm would be that it already exists, there's no other reason to use it, just increases ambiguity, you cant pick any name you want they're mostly gone, slower, different credentials to manage, search that actually works, difficult to set up private repos compared to how component does this etc

@visionmedia, I understand that Component does a lot more things than just package management, and actually the approach it takes to solving that particular problem (ie using github as the registry) seems novel and certainly has its benefits as you point out. However, I still haven't quite grasped what sets Bower apart from NPM - you can specify git urls with NPM to avoid the central point of failure (I think), so that probably isn't it, perhaps it has something to do with being non-commonjs? Or perhaps it deals with static files in some more universal way? Maybe I'm missing something obvious...

I guess it appears subtle coming from node land, but if universality is the goal, Bower's differences make sense. Maybe I can write my node packages for Bower, haha..

medikoo commented Sep 19, 2012

@visionmedia sorry but I don't get most of your points. I don't see how Bower can be step forward from NPM, from where I'm standing it looks as step backwards.

With NPM we can manage cross-environment modules that can be used both on server (in Node.js) and on client in browser (with help of tools like Webmake or Browserify). Can I use bower to install packages for Node.js? I don't see such possibility, it looks like Bower again jails us in strictly client-side world.

NPM has really great dependency management design, do Bower provides something that is comparable?

you cant pick any name you want they're mostly gone

Can you elaborate? What is your solution to that? Starting new package management system, so you can grab good names first? ;)
If you want to use already taken names in private projects, you can easily do it with NPM just by providing url's instead of version numbers in dependencies section.


I never had issues with npm in command line, it's always as fast as expected. I remember though it had some problems in the past, but that seems to be gone for good. Still even if there are problems, it's solvable.

different credentials to manage

Can you elaborate?

search that actually works

Indeed npm website is far from perfect now (not sure about command line search, don't use it much), but it's just the question of current solution, not core design, it definitely will be improved. NPM has also great third party applications that allows fast search as expected e.g.: http://geekple.com/nodejs or http://eirikb.github.com/nipster/ so it's no that you can't search effectively

tj commented Sep 19, 2012

I wasn't talking about bower, https://github.com/component/component

tj commented Sep 19, 2012

and once again npm is an ambiguous place to put client-side anything IMO, I dont want to search around for what might be designed for the client, nor do I want to fight will naming and add -component or similar to all my things, it only conveniences node users, that's a bad way to think


addyosmani commented Sep 19, 2012


@jperl jperl referenced this pull request in opitzconsulting/uitest.js Apr 2, 2013


added bower component file #18

Package.json, and component.json, and bower.json, and lions, and tigers, and bears, oh my!

Seriously though, this is reaching the boiling point of idiocy. Juggling12 .json files to satisfy the technically-baseless deviations of all these quaint package managers is tiring. Let's take a swig of common sense and use unique keys on package.json, as all the logically-minded respondents to this issue have echoed.

@fat - your idea of a unifying ___.json seems best, perhaps we can talk about evangelizing this at a high level?

tj commented Jun 6, 2013

don't forget xtag.json

We're killing it off for this very reason, and I fought it from day 1.
_sound of wind being taken from sails_
On Jun 6, 2013 1:25 PM, "TJ Holowaychuk" notifications@github.com wrote:

don't forget xtag.json

Reply to this email directly or view it on GitHubhttps://github.com/bower/bower/pull/62#issuecomment-19071697

medikoo commented Jun 6, 2013

People, just use NPM and move on ;-)

tj commented Jun 6, 2013

it just took 2 minutes to publish a module to npm, no thanks haha

@visionmedia "it just took 2 minutes to publish a module to npm, no thanks haha" - to be clear TJ, I'm not saying your non-Web-Components-components project shouldn't have its own registry, just that it (and Bower) shouldn't force me to become a package manager json-based management file manager. The current state of affairs feels very much like this:


isaacs commented Jun 8, 2013

@visionmedia "it just took 2 minutes to publish a module to npm, no thanks haha"

I just fixed a file locking bug that was adding 10s of latency repeatedly. npm i npm -g and you'll probably be very happy.

tj commented Jun 8, 2013

@isaacs awesome! much better :D

@visionmedia, This is why there's 90 package managers out there? Because it takes too long to upload? And you're resolving the problem of ambiguity in package management by calling your projects "bower" and "component"? At least NPM has "Package Manager" right there in the name. I don't even know what your projects do at first glance.

Can ya'll please stop with your vanity projects and help update npm? @medikoo and @csuwldcat are right.

tj commented Jun 17, 2013

you're right, let's all use the same thing and never innovate ever, stagnation is FTW. I've come to realize there will always be fragmentation, but I also realize if there is no fragmentation there wont be much innovation either. It's definitely a double-edged sword, but at the end of the day use what you like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment