Document which jQuery modules are relied upon

[lukemelia]

This would allow people to do a custom build of jQuery if they would like: https://github.com/jquery/jquery#modules

[wagenet]

@lukemelia Are you volunteering? It should be a matter of running the tests with a custom build and seeing what fails.

[lukemelia]

Yes, you can assign me. On a ongoing basis, do you think we would want tests to run with the necessary custom build, with all of jQuery, or both?

[wagenet]

Good question. I think we might want to consider just changing the official dependency to be a subset of jQuery and just run tests against that. If we can run against a subset we should be able to run against the full thing in theory. We could also make the tests do both if we thought that was helpful.

[wagenet]

/cc @rjackson

[lukemelia]

Update: I spent about 30 minutes looking into this and found that jQuery's custom build system made it easy to create builds that don't work. It will be more complex than I expected to figure out which modules are necessary.

[rwjblue]

How about this: run through the main modules, build jQuery without them (one at a time), run our test suite, and document the failures/errors by module. Then start picking off the lowest hanging items one at a time.

@lukemelia - Does that sound like a decent plan? If yes, I can devote some time to the first pass this week...

[lukemelia]

Seems reasonable, Robert!—
Sent from Mailbox for iPhone

On Sun, Dec 22, 2013 at 6:55 PM, Robert Jackson notifications@github.com
wrote:

How about this: run through the main modules, build jQuery without them (one at a time), and run our test suite, document the failures/errors by module. Then start picking off the lowest hanging items one at a time.

@lukemelia - Does that sound like a decent plan? If yes, I can devote some time to the first pass this week...

Reply to this email directly or view it on GitHub:
#3791 (comment)

[ebryn]

I've had luck on modern browsers using a custom jQuery 2 build with these flags:

grunt custom:-ajax,-ajax/script,-ajax/jsonp,-deprecated,-dimensions,-effects,-event-alias,-offset,-sizzle

HTMLBars will require even less :D

[wagenet]

@rjackson ping.

[locks]

I just finished the first pass at this and I managed to remove more dependencies than I was expecting to. Results are up at https://gist.github.com/locks/cdbd04e6a2f9cefe8304.

@ebryn I tried removing sizzle but it broke quite bad, did you supply an alternative?

For the next pass I'm going to look into the failing tests and see if I can replace jQuery with native code.

[tomdale]

@locks: Be careful with that one. jQuery.remove, for example, does a lot of things that we implicitly rely on to keep our memory consumption down. Off the top of my head, jQuery unbinds events and clear any data that may have been added by jQuery.data, which will otherwise leak. Changing to using native DOM manipulation will introduce a memory leak into any Ember apps that use, for example, jQuery UI or jQuery Mobile.

[locks]

@tomdale how do you suggest I make sure I don't introduce regressions?

My general plan was to err on the side of aggressiveness, and then re-introduce the modules when problems were detected.

[trek]

We're pretty close to removing jQuery as a dependency. There were several stabs at integrating jQuery's custom build system to work with rake-p and Broccoli, but it seems silly at this point.

[locks]

@trek curious about updates on this front