ERROR - This language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration.

On

$ npx google-closure-compiler --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20181210
Built on: 2018-12-12 22:34

compiling

if (performance.now() >= 0) {
  function foo() {
    console.log(performance.now());
  }
  foo();
}

gives

$ npx google-closure-compiler --js=src.js --js_output_file=out.js --language_in ECMASCRIPT5
src.js:2: ERROR - This language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration.
	function foo() {
	^

1 error(s), 0 warning(s)

I don’t think this error is correct. Functions defined inside a block do work in non-ES6 browsers, and the code used to compile properly in older version of Closure compiler when using --language_in ECMASCRIPT5 flag. This issue started to appear after I updated Closure to a newer version. My older Closure version was

Closure Compiler (http://github.com/google/closure-compiler)
Version: v20171023
Built on: 2017-10-26 19:00

I do not expect the function foo in above example to have block scope visibility, but due to reasons X beyond my control, I am compiling code that has instances of functions defined inside blocks - the code as written does not care about scope (in the instances that occur, the functions are used locally at block scope, and don’t mind if the visibility of the functions extends to function scope)

Did Closure drop support for defining functions with function scope in ES5? Or is there a flag to allow enabling this? I’d like to update to a newer Closure compiler version, but this causing a bit of headache.

[juj]

There’s not a lot of reason to supply --language_in unless you’re trying to enforce that your input definitely won’t use any newer features.

This is the exact reason why Emscripten is using --language_in ECMASCRIPT5 - it wants to enforce that user JS code does not use new ES6 features when many developers want to build projects that have backwards compatibility far back to old browsers.

The issue isn’t older browsers, it’s newer ones and differences in behavior between strict and sloppy mode.

I do appreciate and acknowledge the semantical difference with the two scoping rules, but the issue here is not old browsers, or the difference in behavior, but the fact that Closure no longer is able to process valid ES5 code whereas it used to before. Surely Closure does model (used to model?) sloppy mode scope for function definitions e.g. when --language_in=ES5 --language_out=ES5 is used? It feels like a regression that it no longer does.

Could Closure treat the scope according to the --language_in= directive that is passed? I.e. --language_in=ES6 would treat functions with block scope, and --language_in=ES5 (or whichever ES spec first had the semantical change) would treat them with function scope?

[brad4d]

@shicks may have more context

The change to consider block scoped function declarations was made about a year ago. The issue isn’t older browsers, it’s newer ones and differences in behavior between strict and sloppy mode. For example:

(function() {
   var x = [];
   f();
   {
     function f() { x.push(2) };
     f();
   }
   function f() { x.push(1) };
   f();
   // logs [1, 2, 1] in strict mode
   // logs [1, 2, 2] in sloppy mode due to hoisting of outer definition
   console.log(x);
})();

More details available here. https://www.ecma-international.org/ecma-262/6.0/#sec-block-level-function-declarations-web-legacy-compatibility-semantics

We basically decided that the best way to get consistent behavior and avoid nasty surprises for the user was to insist on treating block-scoped function definitions as an ES6 feature.

Since you say you cannot modify the code you’re working with, the best option is probably to just set --language_in=ES6 --language_out=ES5.