[Feature Request] ES6 support for the uglifier

[ThorstenBux]

To me it appears that the uglifier-js used in version 1.37.22 does not support ES6 syntax. It refuses to work with arrow-functions (=>), it refuses to work with default values for function parameters ( var x = function(x=1) ), it refuses to work with the new variable declarations ( let ), it refuses to work with template strings (backticks '`' eg: var s = `test ${i}` )

[kripken]

Correct, this is a current limitation. Some discussion about one possible way to solve this is in #6000, but currently as far as I know no one is working on it. It would be great if someone could.

[ThorstenBux]

Is it possible to change the uglifier? using this https://github.com/mishoo/UglifyJS2/tree/harmony for example?

[kripken]

Sadly no, it's not that easy. We use an older version, Uglify1, and not Uglify2. There's a big API difference between 1 and 2, so migrating to Uglify2 would be as easy as migrating to Babel as suggested in #6000.

With that said, neither is extremely hard. Probably a few weeks of work. Most of the work is to rewrite a small number of passes we have from Uglify1 to the new API - it's a small number since we don't need to modify any asm.js passes, just the ones that run on generic JS, not many of those.

[curiousdannii]

I didn't realise that this was an issue not just for the optimiser, but also for parsing library files. :(

[kripken]

Only when they are parsed by the optimizer, though. If JS isn't being optimized (-O0, -O1, or if JS opts are disabled in higher opt levels), then it's just copied through. Unless I'm missing something?

[curiousdannii]

Oh, you're right, sorry. I'm building with -O3.

[saschanaz]

Personally I don't like what Emscripten does with npm packages, can we install from npm instead of copy-pasting whole packages into the repo?

[kripken]

Yeah, in general it would be good to use npm properly for upstream things. The Uglify1 code we use is an exception though since it's been modified and exists only here (so I'm not sure of the benefit of using npm for it).

[curiousdannii]

How is UglifyJS called? Pass a string in, get a string out? Do we use the UglifyJS parser for any other purposes? If it's used mostly as a closed box then replacing it will be more straightforward.

[kripken]

We use it for asm.js in some ways that are irrelevant to this topic. For the non-asm.js stuff that is relevant, we have 2 main uses:

• Just use it to minify whitespace. We do that in -O2 and above by default. This is a black box use and is easily replaced.
• A few JS optimization passes run on the non-asm.js code. In these cases, Ugilfy generates an AST, which we then optimize, then pass back to Uglify to get the JS. To replace these, those passes would need to be rewritten to use the a new AST (of whatever thing we switch to). There are few passes here (JSDCE, the metadce helper code) and they are fairly short, and we have tests written that will make verifying the rewrites easy. But this will take some work, probably more than a few days.

[curiousdannii]

Just use it to minify whitespace. We do that in -O2 and above by default. This is a black box use and is easily replaced.

Is this the code, and could this function therefore be replaced with one using Babel? If so it could be an easy place to start. However it does receive the ast, not a string...

https://github.com/kripken/emscripten/blob/5952e749af724ee8c1c3838e7ed8497c816d051b/tools/js-optimizer.js#L171-L178

[kripken]

Yes, that's it. The ast is generated near the bottom of the file, as we read the input and parse it.

Probably we'd need a new file for Babel. So there would still be the current js-optimizer (still used on asm.js), and the new one would provide the same external interface (but just support the small set of passes we port to Babel).