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
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent