Replying to [comment:7 wyuenho@…]:
This is not a proof. Bower used to use the
component.json file name before switching to
bower.json, most of these uses can be related to that. Even the first result on your linked search clearly refers to bower:
Actually, I'd be quite surprised if most of these references weren't created specifically for Bower. BTW, this name clash shows that the name
component.json might not have been the best choice.
Component, Bower and Browserify are the 3 main client-side packagers out there now. They are all terrible, but all necessary.
Browserify is not a package manager, npm is.
Also, if your UMD block work with Browserify, it'll work in Component. They work pretty much the same way.
"Pretty much" the same way or really the same way? I'm concerned e.g. about how
this is defined in all of them since in regular client code it's equal to window but in Browserify it's the
module.exports object. How does component handle that?
As to the question of burden, Component's idea of a component is fundamentally different from Bower/Browserify/npm. A component in Component consists of not only JS, but possibly HTML templates, CSS, fonts and images. You cannot express this in package.json, hence component.json was invented. Bower has its own bower.json as well.
Sure, it *can* contain HTML/CSS/etc. but it doesn't *have to*. Similarly to how npm uses .gitignore if .npmignore is not present, I still don't see why component couldn't just re-use package.json if component.json is missing.
I'd strongly urge you guys to support Component. Lots of components now depend on jQuery but they all maintain their own local copies. Not supporting Component upstream only pushes the maintenance nightmare downstream.
Can you name some major examples? The more the better.
Besides, it's really not that hard. You just define component.json once and updates it version number everytime you do a release and that's it. You are already doing everything else that's necessary.
Sure, we can do it if that's really all that's needed. I'm just afraid it's not all; supporting browserify also seemed easy at first look but we spent a lot of time & commits on making it work (and since the most recent browserify-related commit is really recent, I'm not 100% sure it works correctly now).
What you could do is create a separate jquery-component npm package & publish to it a 2.1.0-rc1 tag from the jQuery repository with only one change - the addition of the component.json file. Then you could check if it really works as expected and that there are no problems with using jQuery with component in such a setup. If all works fine (and if component is really that popular), we can add it. But I'd like to take the initial testing burden out of jQuery core team shoulders, we've been spending way too much time on package-management related issues recently.