In 1.16.2
-> 1.16.3
, the closure compiler was updated.
1.16.2
jand@Desjani:pictoperfect-buildenv>java -jar src/uiBuild/yymmdd-HHMM/lib/util/closureCompiler/compiler.jar --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20160911
Built on: 2016-09-13 16:51
1.16.3
jand@Desjani:pictoperfect-buildenv>java -jar src/uiBuild/yymmdd-HHMM/lib/util/closureCompiler/compiler.jar --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20200112
Built on: 2020-01-13 22:21
That's quite a jump, of over 3 years.
A new build, created with util [email protected]
, fails on legacy infrastructure.
The reason is that the closure compiler outputs a more modern version of JavaScript. As an example, 1.16.3
outputs shorthand property names:
c.definitions = {
Math,
window,
global: window,
module: k.selfResolving(function(a, b) {
…
where 1.16.2
does not:
root.definitions = {
…
Math: Math,
window: window,
global: window,
module: expression.selfResolving(function(mid, lazy){
As far as I know, shorthand property names are an ECMAScript 2015 feature.
From the closure compiler release notes, I learn that a command line property --language_out
was added in release
The release notes for v20170806
say
August 6, 2017 (v20170806)
…
ECMASCRIPT_2017 is now the default language mode.
…
The output language defaults to ES5 instead of to the input language.
…
The release notes for v20170806
say
August 5, 2018 (v20180805)
You can now specify STABLE for input and/or output language level to request the latest version of JavaScript that is fully supported by the compiler. Currently, this means ES_2017 for input and ES5 for output.
I can find no other references to changes in the output language level in the release notes, so I need to assume that it is
still (intended to be) ES5. So either this is wrong, or the dojo build system is actively requesting another output language level. I cannot find prove of this. Yet, experiments show that the new setup by default generates at least ECMASCRIPT_2015
.
Workaround
The more recent closure compiler supports a --language_out
command line property;
v20200112
--help
says:
--language_out VAL : Sets the language spec to which
output should conform. Options:
ECMASCRIPT3, ECMASCRIPT5, ECMASCRIPT5_
STRICT, ECMASCRIPT_2015, ECMASCRIPT_20
16, ECMASCRIPT_2017, ECMASCRIPT_2018,
ECMASCRIPT_2019, STABLE
After much searching, I found out that we can add a optimizeOptions
property to our build profile build.profile.js
:
…
mini: true,
optimize: "closure",
layerOptimize: "closure",
optimizeOptions: {
languageOut: "ECMASCRIPT3"
},
stripConsole: "normal",
…
that generates a working build.
languageOut: "ECMASCRIPT5"
generated a build that does not work, so it seems that 1.16.2
-> 1.16.3
does a jump from ECMASCRIPT3
to ECMASCRIPT_2015
or later.
The use of optimizeOptions
in the build profile is not documented. But, in our build process at least, it is copied into bc
, which is included from util/build/buildControl.js
, which is used in util/build/transforms/optimizer/sendJob.js
which calls util/build/optimizeRunner.js
, where it is used as command line argument in the runJava
call.
Suggestion
This is quite a jump for a patch version 1.16.2
-> 1.16.3
.
I suggest
- releasing a
1.16.4
where
- the
--languageOut
parameter passed to the closure compiler defaults to "ECMASCRIPT3"
(by adding it in util/build/buildControlBase.js
, which would then be used both by util/build/transforms/optimizer/sendJob.js
and util/build/transforms/optimizer/closure.js
); alternatively, we can try to use the closure compiler option --browser_featureset_year
- the use of
optimizeOptions.languageOut
in the build profile is documented
- removing the default
--languageOut
parameter passed to the closure compiler not earlier than 1.17