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.

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.

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 :)

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.

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

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

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

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

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

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

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.

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.

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

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

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.

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

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?

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

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

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

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

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

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? : )

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.

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

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?

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

@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

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

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

+1

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?

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//pull/62#issuecomment-19071697
.

People, just use NPM and move on ;-)

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:

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

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

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.