cat lol.js
let a = [0, 1];
for (var x of a) {
}
java -jar ~/code/compiler.jar \
--compilation_level=WHITESPACE_ONLY \
--js_output_file=/dev/stdout \
--language_in=ECMASCRIPT6_STRICT \
--language_out=ECMASCRIPT5_STRICT \
--formatting=PRETTY_PRINT \
--js lol.js
'use strict';var a = [0, 1];
for (var $jscomp$iter$0 = $jscomp.makeIterator(a), $jscomp$key$x = $jscomp$iter$0.next();!$jscomp$key$x.done;$jscomp$key$x = $jscomp$iter$0.next()) {
var x = $jscomp$key$x.value
}
;
It would also be pretty cool if --use_types_for_optimization --new_type_inf caused the code above to not need the polyfill.
It would also be cool if the compiler was like, hey, this for loop doesn't have side effects. I'm just going to remove it. And a isn't referenced by anything. So the output becomes empty. I checked and all this stuff still gets output, even in ADVANCED mode.
Same issue here. The "for of" loops are converted to polyfill, but the polyfill is not provided to the JS which just plain crashes. I expected Whitespace_only to not try any code modification, but it's not working at all because of this.
Is there a fix planned?
"WHITESPACE_ONLY" is used internally for systems where we are transpiling a single file at a time, and thus don't want to include the ES6 runtime library because it's going to be included once when all the files are brought together. It's a misnomer because we're not just stripping whitespace, we're also transpiling. If you don't need transpilation, you can use --language_out=ES_2017.
@OzoneGrif, will setting the --language_out=ES_2017 option to avoid transpilation be sufficient for your needs? Or maybe just use SIMPLE optimization mode?
This is a low priority issue.
Another internal team recently encountered this, so updating the issue.
At some point we want to separate WHITESPACE_ONLY from what we need for "transpiling a single file at a time without including the runtime libraries", and still output the synthetic $jscomp.* code. I'll make sure that the documentation for WHITESPACE_ONLY mentions it still transpiles code.
See also this:
https://github.com/google/closure-compiler/issues/2950
If it isn't going to include the jscomp.* code, it shouldn't include the polyfills either as it, it is duplicating polyfill code and is still is non-functional. The compiler should produce a functional bundle at least that would be something useful.