Skip to main content

Bug Tracker

Side navigation

#14664 closed feature (wontfix)

Opened January 02, 2014 05:13PM UTC

Closed January 22, 2014 07:58PM UTC

Support the component packager

Reported by: wyuenho@gmail.com Owned by: timmywil
Priority: high Milestone: None
Component: build Version: 1.10.2
Keywords: Cc: timmywil
Blocked by: Blocking:
Description

Apologies if this has been reported before but I couldn't find anything from Trac's search so here it is again.

Since the latest jQuery version already support CommonJS style importing, I think it would be nice if jQuery supports this wonderful packaging system built by TJ Holowaychuk:

https://github.com/component/component

jQuery is one of the last few commonly used component in that ecosystem that doesn't have official support for Component. I was wondering if this could be built into the 1.x and 2.x line.

Attachments (0)
Change History (11)

Changed January 02, 2014 05:16PM UTC by dmethvin comment:1

owner: → wyuenho@gmail.com
status: newpending

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.

Changed January 02, 2014 05:22PM UTC by wyuenho@gmail.com comment:2

status: pendingnew

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.

Changed January 06, 2014 05:37PM UTC by dmethvin comment:3

cc: → timmywil

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

Changed January 10, 2014 02:59PM UTC by m_gol comment:4

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.

Changed January 15, 2014 11:02PM UTC by timmywil comment:5

component: unfiledbuild
owner: wyuenho@gmail.comtimmywil
priority: undecidedhigh
status: newassigned

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?

Changed January 15, 2014 11:35PM UTC by m_gol comment:6

_comment0: 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. \ \ Is this package manager really popular? I haven't heard about it before.1389829027877321

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.

Changed January 16, 2014 05:04AM UTC by wyuenho@gmail.com comment:7

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

Changed January 20, 2014 02:46PM UTC by m_gol comment:8

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.

Changed January 20, 2014 03:34PM UTC by wyuenho@gmail.com comment:9

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.

Changed January 21, 2014 05:30PM UTC by m_gol comment:10

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

Changed January 22, 2014 07:58PM UTC by dmethvin comment:11

resolution: → wontfix
status: assignedclosed

See the PR.