Can you outline what steps we'd need to take to support this?

Would you be able to do a pull request if we decided to support it?

I just deleted the duplicate ticket.

1. There needs to be a component.json file.

https://github.com/component/spec/blob/master/component.json/specifications.md

2. There needs to be a built jQuery distribution for a versioned tag

3. Tag and release.

I can do a PR for the component.json file but the tag needs to include a built JS file, might need to change your build system and release policy for that.

Since you're working on the build stuff timmywil, what are your thoughts on this?

I think we shouldn't support any such files manually. They should be generated in a build step (which means they will be available in the final version). I'm against manually supporting more package manager files or it'll become unmaintainable mess.

I'm fine with this. I think all we need to do is add the component.json file and support updating its version in the jquery-release repo. Anything else?

A question is: do we *really* need it? We're already supporting bower & npm, now we'll add component, in some time another package manager will come and we'll be littered with configuration files.

I'm also quite afraid we'll be fighting with it similarly we did with browserify-related problems. It will turn out our require doesn't have an intuitive signature or sth and we'll just keep tweaking intro.js, breaking a different thing on each update.

Besides, there's a question of burden - why can't component extrapolate its data from package.json? Why do we have to cater to it and not otherwise?

Is this package manager really popular? I haven't heard about it before.

@m_gol Here's the [answer](https://github.com/search?l=javascript&q=component.json&type=Code) to your question. Component is pretty popular. Component, Bower and Browserify are the 3 main client-side packagers out there now. They are all terrible, but all necessary.

Also, if your UMD block work with Browserify, it'll work in Component. They work pretty much the same way.

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.

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

Replying to [comment:7 wyuenho@…]:

@m_gol Here's the [answer](https://github.com/search?l=javascript&q=component.json&type=Code) to your question. Component is pretty popular.

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:

https://github.com/Bochenski/mashups/blob/17af5c03eda26aa2134c2c2e82d3b01a2c11e4e3/yeoman/generator/node_modules/yeoman/node_modules/bower/lib/core/config.js

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.

1. Component is a project started a couple of months before Bower. If anything it's Bower that's hijacked the name component.json, not the other way around. In fact, the reason Bower changed to bower.json is because of Component, and Bower knew of the existence of Component and the steam that it seemed to be getting. Most projects that are still active have already switched to package.json or bower.json. You can Google the history of Bower and Component. The Bower team seems to be at odds with the Component team for some reason.

2. UMD blocks in Browserify and Component work exactly the same way. The global object in both are the module. This makes getting to the window, document etc harder but not impossible, but you have already supported CommonJS style imports anyway.

3. Component doesn't reuse package.json because you can't define anything other than a "main", and "main" in package.json must be a single module ID. This mechanism isn't good for anything exactly pure JS modules. TJ doesn't want to extend package.json like Browserify does, or break package.json like Bower. TJ goes out of his way to avoid name clashes.

4. I maintain Backgrid, all of its extensions depend on Backgrid which in turn depends on jQuery. I'm sure you know Select2 as well. Backbone just recently added support for Component. The fact is, all of them depend on jQuery, but none of them really work because jQuery doesn't have a component.json file.

5. I'd love to help you guys testing out Component. Will send a PR over shortly.

@wyuencho Thanks for your detailed comment. I didn't realize the Component project had started before Bower did.

I answered in your PR with technicalities.

See the PR.