uglify-es compress conditionals: increment erroneously not reached

[sirreal]

Bug report or feature request?

Bug report

ES5 or ES6+ input?

ES5 input using uglify-es@3.3.9

Uglify version (uglifyjs -V)

uglify-es 3.3.9

JavaScript input

var index = 0;
var whereIsTheLetterC = 0;

[ 'a', 'b', 'c' ].forEach( function( letter ) {
	index++;
	if ( 'c' === letter ) {
		whereIsTheLetterC = index;
	}
} );

console.log( 'This letter "c" is number 3: %d', whereIsTheLetterC );

The uglifyjs CLI command executed or minify() options used.

--compress conditionals=true

The issue is not observed when:

--compress conditionals=false

JavaScript output or error produced.

var index = 0, whereIsTheLetterC = 0;

[ "a", "b", "c" ].forEach(function(letter) {
    "c" === letter && (whereIsTheLetterC = ++index);
}), console.log('This letter "c" is number 3: %d', whereIsTheLetterC);

Detailed description

In the samples above, the input will produce:

This letter "c" is number 3: 3

The uglified (compressed conditionals) version will produce:

This letter "c" is number 3: 1

You can see that in the input, index will always be incremented. However, in the uglified output, index is prefix-incremented only when "c" === letter evaluates to true.

This bug was discovered in Automattic/wp-calypso#21489

The following is the "real-life" code that exposed the bug:

https://github.com/visionmedia/debug/blob/22f993216dcdcee07eb0601ea71a917e4925a30a/src/browser.js#L90-L102

The bug was noticed in the result of applying uglify-es to the above code as part of a Webpack build using https://github.com/webpack-contrib/uglifyjs-webpack-plugin.

Massive thanks to @ockham for help with this issue.

[sirreal]

The repo used to track this down is here: https://github.com/sirreal/debug-debug

It should be simple to checkout, npm install and npm start to see the issue.

[sirreal]

Note that the issue does not manifest with uglify-js@3.3.15. It appears to be uglify-es specific.

[jsnajdr]

Duplicate of #2908, fixed in 0c4f315c026e6, fix released in uglify-js@3.3.11, but never merged to the harmony branch.

#2908 (comment) is interesting:

I currently have no plans to work on harmony - fix is in the latest release of uglify-js.

@alexlamsl Does that mean that uglify-es is unmaintained and we shouldn't use it?

[kzc]

Does that mean that uglify-es is unmaintained and we shouldn't use it?

uglify-es can still be useful even in this state by disabling the options that don't work for a given code base.

You can try another ES6+ minifier, but every alternative has their own problems - whether it's a JVM dependency, configuration complexity, slowness, or bugs of their own. All such projects have the same lack of contributors.

Anyone is free to fork uglify-es, apply patches, fix bugs, and maintain their own copy. People don't appreciate that this is an unpaid volunteer effort that requires a lot of work - and frankly, a lot of grief.

[sirreal]

@kzc I understand that open source work can be thankless. If anything on this issue has caused grief, you have my apologies 🙇

We all greatly appreciate this project and the amount of work that goes into it. It provides a lot of value for a lot of other projects ❤️💚💜💛

Please take the question at face value. If we know that uglify-es won't receive bug fixes then we can consider the appropriate steps to take 🙂

[alexlamsl]

@sirreal I think @kzc has already answered your query, but just to clarify:

• I will only maintain master a.k.a. uglify-js from now on
• I only have commit rights to this respository, which means I cannot grant others commit rights (or rename this repository)

(Note: I am not the only maintainer for this repository, so I can only speak for myself here.)

[sirreal]

Thanks for the information @alexlamsl 👍

[jsnajdr]

@alexlamsl I'd like to better understand the relationship between the master and harmony branches. With my very limited knowledge of the project, I would expect that the harmony branch is the one that receives most attention and is eventually merged into master. It's a superset of the ES5-only master, with added support for ES6+ features like arrows and classes, or isn't it? What is the rationale behind the decision to work only on the ES5 version in master?

How hard would it be to regularly merge master to harmony and keep both packages up to date? Can we offer any help?