DISCUSS: Should the default output language be `NO_TRANSPILE`?

[brad4d]

It is now possible to output ES_2017 code, and in future we would really prefer to stay more on top of the output language level.

Currently the default output language level is still ES5 to support the most possible browsers by default.
Would it now make sense to make the default NO_TRANSPILE, so you get the same language level out as you get in unless you specify otherwise?

Note that we're still almost certain to support new language levels as input before they are supported for output (just with a much smaller gap between). In such cases NO_TRANSPILE wouldn't work and we'd need to generate an error if the output language weren't explicitly specified.

Or would we default to the highest possible? That seems dangerous, since a new release of the compiler that silently switches the output from, say, ES_2019 to ES_2020 would break projects that were unintentionally relying on the fact that the default was ES_2019 just because we hadn't yet added support for ES_2020

[brad4d]

@ChadKillingsworth
what is your opinion of this?

[brad4d]

Internal issue created http://b/128311967

[concavelenz]

Requiring the --language_out would be "safe" but perhaps not the best user experience.

[ChadKillingsworth]

The vast majority of usage externally is still ES5. I would leave the default there. Once Internet Explorer usage drops substantially I would expect a higher language level to be warrented.

[brad4d]

@ChadKillingsworth thanks for your input.

[concavelenz]

@ChadKillingsworth Why do you feel ES5 is still dominant?

[ChadKillingsworth]

For the output language? I know of zero projects which output ES6+ only. I know several that output ES5 and ES6. But the majority of projects I work with or contact still transpile to ES5 only.

[zavr-1]

All my code is written in ECMA2018 it wouldn't make sense to build for 2018 when I publish for the web because it would break a lot of user-agents like the iPhone iOS 8 that I'm still on because I have no memory to update (please don't hack me), so in general it's would be one more argument to pass if you switched to the NO_TRANSPILE but I think you should keep it 2015 because it's the safest.

[GHLover]

Why can language out not be ECMA2018? This breaks a lot of code. For example, regexp "dotall" support is in ECMA2018. Since closure always must transpilte to ECMA2017 or lower it will break any proper regexp using dotall /s flag

[brad4d]

@GHLover we should be making ES_2018 and ES_2019 output available very soon, possibly the next release.
Transpilation happens about mid-way through compilation, after checks but before optimizations. We have to get the optimizations updated for the new language features before we can output them.

[ctjlewis]

I would definitely say so. Setting both flags to STABLE by default, coupled with the internal difference between STABLE_IN and STABLE_OUT, leads to transpilation by default (even with --WHITESPACE_ONLY flag) as seen in #3637.

I'd say that --NO_TRANSPILE language_out default is the most logically sensible decision, even though most projects are ES5, a user would not end up running into this issue unless they explicitly tried to target a different output language or what have you. The change would effectively solve issues by preventing them in the first place. Seems like all upside.

[brad4d]

@christiantjl If NO_TRANSPILE were the default, then projects using the default would end up broken when we add new features that are understood only by the front end (checks) of the compiler and not the back end (optimizations) yet.

Also, it would mean that the default output level would change a lot more frequently, likely taking people unpleasantly by surprise.