-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Google closure compiler js #5464
[WIP] Google closure compiler js #5464
Conversation
OK, so compilation finishes fine, but returns bad status code (because of warnings), which is impossible to fix with arguments because of google/closure-compiler-js#73 |
This PR is mostly whitespace changes. If you want to do such trailing whitespace removals, any chance you could separate those to a single commmit in a separate PR? Then reviewing this will be easier, and if someone is reading the PR later, they'll have a to the point view to the actual changes. I can also prepare such a PR if you'd like. |
Sorry about that, my IDE removes those whitespaces automatically whenever the file is edited. It is in separate commit already (with documentation tweaks). I'll separate it later, this PR is still not ready to be merged anyway, there are some warnings/errors reported by Closure Compiler that I have to fix somehow so that it stops reporting status code |
Authored #5469, although I'm thinking perhaps it's better to leave these things out, since even if we cleaned trailing whitespaces up, they will inevitably creep back in since there are lots of authors who use different IDEs, and such changes make tracking history and changes more difficult, and |
Thanks for looking into this, removing the java dependency would be great. Compilation time and memory usage is something to look at, but even if it's somewhat slower I think it's worth doing this. |
|
👍 and double- 👍 if it means we can start using ES6+ features and still support older browsers via transpiling. |
@dschuff, it does mean ES2015+ is on the horizon! |
…pm dependency). Some new externs added to please Closure Compiler.
…ences left) except for `verify_emscripten_environment.rst` file (examples in this file should be rewritten)
…e JavaScript code inside
Fixes to externs (added File API externs).
… but don't cause everything to fail)
Fix Js optimizer to properly work with added suppression comment (resulted in corrupted JS build). More externs fixes.
I've fixed some compilation errors and restored some trailing spaces to reduce diff and ease reviewing. Looks like this is ready for initial testing! I'm not sure how Can we disallow closure compiler to be used with Alternatively I think we can move to newer Java version of Closure Compiler first (most changes here are actually not related to JS version) and merge JS version as soon as mentioned issue is fixed. I've executed UPD: Make sure to use newer Node version than is included with emsdk by default, I've just changed symlink to v8.4.0 installed globally on my system. |
Yes, the interpret modes are mainly for testing. Ok to disable closure there.
That sounds like a good idea - less big change in one PR is better. |
Great, I will prepare another PR with updated Java version of Closure Compiler and changes necessary for it to work properly. Then will rebase this one against that new PR. |
Small update on this topic: apparently latest versions of Closure Compiler on NPM support both Java and Node.js operation, which means faster compilation time when Java runtime is available and fallback to JavaScript version if not, kind of the best of 2 worlds. |
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant. |
I think we should still do this at some point. |
I believe this was fixed in #9989 |
Replacing Google's
closure-compiler
that requires Java withclosure-compiler-js
that works in Node (which should be present anyway).Things that are left to be done here:
verify_emscripten_environment.rst
with something other than Java-s WASM=1 -s "BINARYEN_METHOD='interpret-asm2wasm'"
takes enormous amount of time and fails without descriptive errors (asmjs
andnative-wasm
methods are good, likely related to Bad compile time performance google/closure-compiler-js#24)Fixes #4539
Probably obsoletes #5109
Enables #5185 (
ECMASCRIPT5
needs to be changed toECMASCRIPT6
for this, which is trivial)