Turn off inlining in optimization until UglifyJS issue is fixed.

[webpack-bot]

This minimization bug has been open for almost two months: mishoo/UglifyJS#2842. It has been referenced here elsewhere. The bug occurs when UglifyJS attempts to inline a call to a function with a variable of the same name as a variable in the calling function. Symptoms usually include "is not defined" or "assignment to constant variable".

In my experience, it's both easy to fall into and extremely time-consuming to diagnose.

I'd suggest turning inline: false in Webpack 4 until this is fixed. From the comments, it looks like UglifyJS2 is suffering from a lack of contributors with the skills and bandwidth needed to deal with things like this.

All of the Webpack 4 blogging has been about "Just let us do it for you." IMHO, to fulfill the implied promise, I think you need to be reactive to component issues like this.

Related: optimization.minimize and optimization.minimizer (along with the rest of optimization) need documenting.

For this particular issue, I'm using:

{
optimization:
            minimizer: [
               
                new UglifyJsPlugin({
                    parallel: true,  // Webpack default
                    cache: true      // Webpack default
                    uglifyOptions: {
                        /*
                            inlining is broken sometimes where inlined function uses the same variable name as inlining function.
                            See https://github.com/mishoo/UglifyJS2/issues/2842, https://github.com/mishoo/UglifyJS2/issues/2843
                         */
                        compress: { inline:false },
                    },
                })
            ],
}

---

This issue was moved from webpack/webpack#6798 by @evilebottnawi. Original issue was by @estaub.

[alexander-akait]

/cc @michael-ciniawsky what do you think about this?

[gil0mendes]

Today I ran over this issue, this would be nice to be fixed. Until then, disabling the minification is a good temporary workaround.

[jamesopti]

All of the Webpack 4 blogging has been about "Just let us do it for you." IMHO, to fulfill the implied promise, I think you need to be reactive to component issues like this.

+100 Couldn't agree more.

[michael-ciniawsky]

@evilebottnawi We can disable inlining by default, there will likely be no other option in the near future 😞. This plugin will definitely become obsolete anyways if uglify won't actually be maintained for ES2015+ code

[alexander-akait]

@michael-ciniawsky yep, let's do this, and we can improve babel-minify plugin for future 👍

[alexander-akait]

@michael-ciniawsky i can migrate cache and parallel options very fast 😄

[Reinmar]

We've run into this issue when trying to add support for building CKEditor 5 with webpack 4 (https://github.com/ckeditor/ckeditor5-dev/issues/371).

What I found is that uglify-es is not supported anymore (#262).

So, in the light of this, I'd say that disabling inlining misses the point. We may soon run into another issue with uglify-es and what's then? Will we be disabling next uglify's features?

[alexander-akait]

@Reinmar we can:

1. Migrate on uglify-js
2. Disable some option by default, but uglify looks very buggy and in long/mid term it is not solve
3. Migrate on babel-minify (looks it is time for this).