Question: Switch to maintained uglification module?

[sirreal]

It appears that uglify-es will not be maintained. See mishoo/UglifyJS#2908 (comment) and mishoo/UglifyJS#3010 (comment).

There are known issues which affect the behavior of code transformed by uglify-es. I recently came across a pesky production only bug (Automattic/wp-calypso#21489) which was caused by an issue with uglify-es (mishoo/UglifyJS#3010).

I'd like to consider what can be done to ensure that this plugin reliably transforms code that will maintain the same behavior as pre-transform code. Some ideas:

• Switch to uglify-js
• Switch to another module like babel-minify (Turn off inlining in optimization until UglifyJS issue is fixed. #264 (comment))
• Use a set of default options that disable uglification features known to be problematic (Turn off inlining in optimization until UglifyJS issue is fixed. #264, Inline function optimization fails to define some arguments #265)
• Encourage contributions to port uglify-js fixes to uglify-es

cc: @jsnajdr @ockham

[alexander-akait]

@sirreal thanks for issue, let's wait response from other contributors, i was confused why uglify-es will not be maintained. How we can handle es5+ syntax 😕 ?

[sirreal]

How we can handle es5+ syntax 😕 ?

Not sure if this question is for me or other maintainers. I'll just reference #264 proposing a babel-minify as an alternative (#264 (comment)).

[estaub]

@evilebottnawi - see comments on mishoo/UglifyJS/issues/3010, mishoo/UglifyJS/issues/2842

...which suggests another option, a wee bit out of scope: use a forked, maintained uglify-es (a.k.a. "harmony" in the comments).

[alexander-akait]

@estaub do you have time to maintenance new package?

[estaub]

@evilebottnawi I've not the skill, and if it wasn't obvious, I was being ironic in calling it "a wee bit out of scope"! But this is a big enough problem that someone might pick it up and/or fund it.

Also, if anyone personally knows Alex, the developer who's dropping support for uglify-es, they might want to reach out and try to understand better where he's at. uglify-es has been a huge contribution; if there are conditions under which he'd want to continue with it, he's owed every opportunity.

[Reinmar]

I found this issue when we encountered the problems described in #264.

If I understand it correctly, webpack 4 introduced a production mode which defaults to uglifyjs-webpack-plugin which, in turn, relies on uglify-es. This is all a bit odd, taken that uglify-es is not maintained anymore.

I know that making long-term decisions in the JS world is hard, especially for OSS projects which need to consider backwards compatibility and trends. So, I can't tell you that going with babel-minify is the best choice. However, what I can tell from my own experience (and preference) is that:

• Speed doesn't have to be the most important factor; reliability is more important,
• We use babel-minify to build CKEditor 5 (fairly big ES6 project) for about a year now and we had one issue so far (which was fixed),
• The idea to use Babel (or babylon to be precise) as a base of a minifier sounds quite future-proof. New versions of ES should be supported (at least in this aspect) out of the box as long as Babel will be maintained. As far as I understand, uglify-es has a built-in parser which means that its maintainer will need to catch up with new ES versions.