Add control over JS version used in input and output of emscripten

[sbc100]

This allows users more control of the version of JS they want
to produce and the version they want to use in their input.

It also fixes a bug where we were introducing non-ES5 features into our
output files by using closure with --language_out set to NO_TRANSPILE and
--language_in set to ECMASCRIPT_2020.

Fixes: #12628

[sbc100]

I know it will probably make @RReverser sad to see this extra setting needed just to use modern JS.. on the other hand we do hope to bump to the default to ES6 in the very near future.

[sbc100]

This is first step towards #11984

[RReverser]

I know it will probably make @RReverser sad to see this extra setting needed just to use modern JS.. on the other hand we do hope to bump to the default to ES6 in the very near future.

If I understand original issue correctly, Closure Compiler introduces a new syntax even when user didn't write it, and even when using NO_TRANSPILE?

It can be very surprising for users if so, and I agree fixing it is more important for now.

[sbc100]

I know it will probably make @RReverser sad to see this extra setting needed just to use modern JS.. on the other hand we do hope to bump to the default to ES6 in the very near future.

If I understand original issue correctly, Closure Compiler introduces a new syntax even when user didn't write it, and even when using NO_TRANSPILE?

It can be very surprising for users if so, and I agree fixing it is more important for now.

Yes, I think my understanding of what NO_TRANSPILE on the output and ES_2020 on the input would do. I guess it makes perfect sense that reducing {foo: foo} to {foo} when the input is ES_2020 is perfectly in line with NO_TRANSPILE since they are both valid in ES_2020.

[sbc100]

I spoke with alon about this and he thinks we should be able to do with without adding so many options.

I'm going to try to make this simpler if I can.

[RReverser]

I guess it makes perfect sense that reducing {foo: foo} to {foo} when the input is ES_2020 is perfectly in line with NO_TRANSPILE since they are both valid in ES_2020.

TBH it doesn't make much sense to me, because I'd expect NO_TRANSPILE to be strictly not transpiling anything at all, and the behaviour you're describing to only apply when someone explicitly sets ES_2020 as both input and output. Instead, it seems they treat NO_TRANSPILE as more of an alias.

[sbc100]

Either way I guess NO_TRANSPILE isn't doing what we would need it to do in this case. I guess we want it to mean: don't do any size reduction that depend on any language features at all, even ones that exist in the version specific by the input. I think being explicit about that output version one way or another is the solution.

[RReverser]

Yeah, sounds fair. It's a shame we already called the ES module option EXPORT_ES6, I feel like now, whatever we add, will be easy to confuse with that one because EXPORT_ES6 sounds like a language version preference too.

[sbc100]

Yeah, that options should really be called "EXPORT_MJS"... perhaps we could make that an alias.

Also, by the way the EXPORT_ES6 option is not necessary if your output file ends in ".mjs" or if you pass --oformat=mjs... Perhaps we should completely deprecate EXPORT_ES6 ?

[stale]

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 30 days. Feel free to re-open at any time if this issue is still relevant.