Adding support for specifying bower configuration in package.json

[iros]

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]

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]

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]

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]

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]

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]

@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]

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]

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

[tj]

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

[iros]

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

[fat]

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.

[ralphholzmann]

@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]

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]

@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]

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]

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

[ralphholzmann]

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

[fat]

@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]

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]

@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]

@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]

@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]

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

[tj]

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]

@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]

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]

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?

[athibaud]

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]

@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]

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

[tj]

@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]

@visionmedia yeah true.

[athibaud]

@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]

@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

[athibaud]

@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]

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.

[jessetane]

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]

@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

[jessetane]

@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...

[jessetane]

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]

@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.

slower

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]

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

[tj]

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]

+1

[csuwildcat]

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.

[csuwildcat]

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

[tj]

don't forget xtag.json

[csuwildcat]

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]

People, just use NPM and move on ;-)

[tj]

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