Unnecessary polyfills included in ES2015 output

[concavelenz]

Async functions cause both "Symbol" and "Promise" polyfills but these are guaranteed to be part of ES2015:

This can be seen with:

// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// @output_file_name default.js
// @language_out ECMASCRIPT_2015
// @formatting pretty_print,print_input_delimiter
// @debug true
// ==/ClosureCompiler==

(async  ()=> {
claims={
    "aud": "mailto:nobody@nowhere.org",
    "sub": "https://nowhere.org",
    "exp": parseInt(Date.now()*.001) + 86400
}

vapidToken=new VapidToken(claims);
await vapidToken.generate_keys();
return await vapidToken.sign(claims);
})();

https://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520ADVANCED_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%2540language_out%2520ECMASCRIPT_2015%250A%252F%252F%2520%2540formatting%2520pretty_print%252Cprint_input_delimiter%250A%252F%252F%2520%2540debug%2520true%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250A(async%2520%2520()%253D%253E%2520%257B%250Aclaims%253D%257B%250A%2520%2520%2520%2520%2522aud%2522%253A%2520%2522mailto%253Anobody%2540nowhere.org%2522%252C%250A%2520%2520%2520%2520%2522sub%2522%253A%2520%2522https%253A%252F%252Fnowhere.org%2522%252C%250A%2520%2520%2520%2520%2522exp%2522%253A%2520parseInt(Date.now()*.001)%2520%252B%252086400%250A%257D%250A%250AvapidToken%253Dnew%2520VapidToken(claims)%253B%250Aawait%2520vapidToken.generate_keys()%253B%250Areturn%2520await%2520vapidToken.sign(claims)%253B%250A%257D)()%253B%250A%250A%250A

[MatthewMerrill]

Looks like they aren't added when I comment out the lines that require them from the runtime files.

Promise comes from the Async Function runtime logic.

closure-compiler/src/com/google/javascript/jscomp/js/es6/execute_async_generator.js

Line 18 in f24dccb

'require es6/promise';

Symbol comes from the generator engine...

closure-compiler/src/com/google/javascript/jscomp/js/es6/generator_engine.js

Line 18 in f24dccb

'require es6/symbol';

...which is needed because of the function $jscomp.asyncExecutePromiseGeneratorProgram that is defined in the async function logic but only used if you are also transpiling away the generators too. If you move that function to its own file or refactor it out I think you can also remove the entirety of generator_engine.

I commented the aforementioned requires for promise, symbol, and generator_engine, and also the entirety of the asyncExecutePromiseGeneratorProgram function and got back as a result:

$ java -jar target/closure-compiler-1.0-SNAPSHOT.jar --js=/tmp/badinjects.js  --language_out=ECMASCRIPT_2015 -O=SIMPLE --formatting=pretty_print

'use strict';
var $jscomp = $jscomp || {};
$jscomp.scope = {};
$jscomp.asyncExecutePromiseGenerator = function(a) {
  function c(b) {
    return a.next(b);
  }
  function e(b) {
    return a.throw(b);
  }
  return new Promise(function(b, f) {
    function d(a) {
      a.done ? b(a.value) : Promise.resolve(a.value).then(c, e).then(d, f);
    }
    d(a.next());
  });
};
$jscomp.asyncExecutePromiseGeneratorFunction = function(a) {
  return $jscomp.asyncExecutePromiseGenerator(a());
};
(() => $jscomp.asyncExecutePromiseGeneratorFunction(function*() {
  let a = {aud:"mailto:nobody@nowhere.org", sub:"https://nowhere.org", exp:parseInt(.001 * Date.now()) + 86400}, c = new VapidToken(a);
  yield c.generate_keys();
  return yield c.sign(a);
}))();

Which is what I would have expected. I think Symbol is also being injected from Es6InjectRuntimeLibraries, is there a reason for it to be required from generator_engine? Could Promise be injected in the same way?

[concavelenz]

The basic problem is that "ensureLibraryInjected" doesn't consider whether the runtime is needed, it just adds it. Similarly, "RemoveUnusedPolyfills" doesn't consider whether the polyfill is need either.

[ChadKillingsworth]

Generators are injected as well when transpiling async/await.

[leidegre]

@ChadKillingsworth is there a way to avoid or "turn of" this injection by the compiler?

I have a lot of files organized as independent modules, the injected stuff adds 400% for each module. In my particular case, I would be better off to just take this cost once but I still want the compiler to compress everything else.

I'm consuming the Compiler class directly and I'm not using the command line interface. I've played around with the various compiler options but to no avail.

Edit: I think I've figured this out. I started using whitespace only mode and then I use the force inject option to ensure that the runtime is at least included once.

[ChadKillingsworth]

@leidegre Yes - --rewrite_polyfills=false

[leidegre]

@ChadKillingsworth I tried that but is still injecting stuff unless I also switch to whitespace only. --rewrite_polyfills=false in and by itself doesn't seem to do it.

[concavelenz]

You still get the runtime that is required in order for the transpiled code to function, what do you see that you think isn't needed?

[leidegre]

@concavelenz Haven't tasted with latest version, but I can work around the issue somewhat by compiling in two steps. I first do a simple compilation to ES2017 and then feed that into a white space only pass that targets ES5. This works, (for the most part) but I've noticed that it sometimes inline so much that the compiler is unable to rewrite a class declaration. I'm handling this case by falling back to a white space only pass of the original source. It's a minor inconvenience and doesn't really matter. We aim to provide support for modern browser environments and just use ES5 as a fallback for old systems that we barely support.

[leidegre]

You still get the runtime that is required in order for the transpiled code to function, what do you see that you think isn't needed?

To answer your question,

I have a bunch of TypeScript files that the TypeScript compiler compiles to a bunch of JavaScript files. These use CommonJS (but I also do syntax transformations that makes it impossible for the closure compiler to treat them as just CommonJS modules). I then send these 1 by 1 to the closure compiler to minify each file. What happened was that the ES6 stuff and other compiler utilities (like async/generator runtime) was injected into each file which caused minified output to grow by about 400% on top of original size. It didn't matter what compiler options I tried. The only way I got around this issue was falling back to white space only optimization. Which appears to do the right thing.

Something fundamental changes between white space only and simple which I think is at least unexpected here but very workable.

[concavelenz]

@leidegre leidegre Seems like you should set the language_out to ECMASCRIPT_2017 ?

[leidegre]

@concavelenz I do. But I need two sets of bundles, 1 for modern browsers, i.e. ECMASCRIPT_2017 and then one ES5 for the rest.

[brad4d]

Created internal Google issue b/119310836

[concavelenz]

For some reason the link to the repro has gone bad:

https://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520ADVANCED_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%2540language_out%2520ECMASCRIPT_2015%250A%252F%252F%2520%2540formatting%2520pretty_print%252Cprint_input_delimiter%250A%252F%252F%2520%2540debug%2520true%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250A(async%2520()%253D%253E%2520%257B%250A%2520%2520claims%2520%253D%2520%257B%250A%2520%2520%2520%2520%2522aud%2522%253A%2520%2522mailto%253Anobody%2540nowhere.org%2522%252C%250A%2520%2520%2520%2520%2522sub%2522%253A%2520%2522https%253A%252F%252Fnowhere.org%2522%252C%250A%2520%2520%257D%250A%250A%2520%2520let%2520vapidToken%2520%253D%2520new%2520VapidToken(claims)%253B%250A%2520%2520await%2520vapidToken.generate_keys()%253B%250A%2520%2520return%2520await%2520vapidToken.sign(claims)%253B%250A%257D)()%253B%250A%250A%250A

[concavelenz]

It isn't immediately clear why RewritePolyfills#removeUnneededPolyfills isn't sufficient here.