Recommended language_out/CompilerOptions.setLanguageOut(...) value

[kwin]

According to https://github.com/google/closure-compiler/wiki/Flags-and-Options the default value for language_out is ECMASCRIPT_NEXT (which matches

closure-compiler/src/com/google/javascript/jscomp/CommandLineRunner.java

Line 673 in bad2009

private String languageOut = "ECMASCRIPT_NEXT";

). However the STABLE/STABLE_OUTversion is still ECMASCRIPT5 (

closure-compiler/src/com/google/javascript/jscomp/CompilerOptions.java

Line 3730 in bad2009

public static final LanguageMode STABLE_OUT = ECMASCRIPT5;

).

Also I see that both ES6 related ticket #949 and #950 are still not being closed.

What is the reason why the CLI default deviates from what is considered STABLE and what is the recommended value?

[lauraharker]

I just closed the two ES6 related tickets, thanks for pointing that out. (#949 and #950). We just overlooked those.

What is the reason why the CLI default deviates from what is considered STABLE and what is the recommended value?

For some context, ac3e330 changed the default CLI value to ECMASCRIPT_NEXT because of some issues with transpilation in WHITESPACE_ONLY mode (#2007).

I honestly don't know if anyone has discussed changing CompilerOptions.STABLE_OUT recently, or if we just overlooked it because most people use the CLI.

[kwin]

@lauraharker Thanks for the reply. What is your personal take about using ECMASCRIPT_NEXT as default for languageOut outside the CLI (I am using some third party minifier leveraging GCC under the hood)? Is ECMASCRIPT_NEXT stable enough to use or is the risk of running into regression when switching from ECMASCRIPT5 (=STABLE) to that value too high?

[lauraharker]

I'd recommend targeting a more modern output than ECMASCRIPT5, so that you get benefits of things like untranspiled async functions (which make stack traces much nicer), & the compiler not warning about things it can't transpile like bigint literals & newer regex flags.

IMO the most stable output target today is ECMASCRIPT_2021; the main thing it doesn't have is public class fields & static blocks. The compiler support for class fields is newer & not as well-tested.

Using ECMASCRIPT_NEXT - this is mainly potentially unstable if using new-ish JS features, like class fields (public class fields are supported, private class fields are a WIP)