Build: Use ES6 modules and remove use of script loading for full build#157
Build: Use ES6 modules and remove use of script loading for full build#157scottgonzalez wants to merge 6 commits into
Conversation
|
I'd recommend viewing the actual diffs from https://github.com/jquery/PEP/pull/157/files?w=1 since every file ended up getting outdented since the closures were removed. |
There was a problem hiding this comment.
I modified the individual source files to not automatically apply global state changes and instead expose methods for applying the changes. These are the three global state changes that were being applied before, preserved in the same order, just moved to the "managing" script.
|
I also removed the use of |
There was a problem hiding this comment.
Not a great variable name, since its own of those (formerly?) reserved words. At least GitHub formats it as a keyword.
There was a problem hiding this comment.
Just remembered: Based on using throws in QUnit, I'd recommend avoiding it, since there's always some shitty tool that doesn't deal with ex-reserved words properly.
|
Overall looking pretty good. |
|
Addressed all of @jzaefferer's comments.
|
|
Changes look good. I've ran the unit tests on this branch and master on Chrome (desktop), iOS Simulator (iOS 7.0.3) and Chrome on Android 5. On master, I consistently get 32 passes, 1 failures, 100% (dunno how 1 failure equals 100%). On this branch, only results on iOS simulator change, with 12 passes, 6 failures, 56%. There's a bunch of different errors, including As for |
|
Updated I'll look into the tests next. |
|
I don't understand why the iOS tests die in this PR, but not in master. The error comes from https://github.com/jquery/PEP/blob/cfc6263a15a642e99d51eef53349171b5aa2515a/src/PointerEvent.js#L64 when the |
|
I just pushed a commit with my proposed workaround. I can remove it if there are objections to that change. |
There was a problem hiding this comment.
Is there any reason to not use grunt-esperanto?
There was a problem hiding this comment.
To be perfectly honest, I don't understand the desire to use modules that don't do much for you. It doesn't even look like the grunt plugin does what we want (no bundling, no custom headers).
There was a problem hiding this comment.
I like to use modules for simplicity over a bigger Gruntfile. To guarantee it will work, we can lock the modules versions, as we already do in QUnit and other projects.
That grunt plugin is indeed missing some crucial features but I already sent a PR.
Fixes gh-154
I went with ES6 modules instead of AMD since it's more in line with future standards and the existing tooling (using esperanto) made the concatenation and transpilation very simple. The result is still a single distributable file which uses a UMD wrapper.