Enhancement: Webpack Tree shaking for removing unused code in the bundle

[CharlesKumar]

current production config is

new webpack.optimize.UglifyJsPlugin({ compress: { warnings: false }, sourceMap: config.build.productionSourceMap, //true parallel: true }),

Question: Is the production config uses --optimize-minimize flag (the answer is no I suppose)

harnessing the static module structure of es6

babel-minify with several presets helps this process with lot of options
(see also webpack-closure-compiler)

The above link has benchmark data (for react.js) with uglify, closure-compiler, betternut, closure-compiler-js and babel-minify

many be this enhancement solve this issue

[LinusBorg]

Hi, and thanks for your suggestions tryon to improve this template.

1. Webpack's tree-shaking is not dependent on any setting that I'm aware of. It's "always on", and we do use Es6 static imports.

2. No, we don't use --optimize-minimize, because it has not use for us. As the webpack docs explain, this flag adds the UglifJS-Plugin, and we already add that ourselves in the production config manually, and with additional options.

Note that the --optimize-minimize flag can be used to insert the UglifyJsPlugin as well.

It's not some additional option we can use, we already do what we can here.

babel-minify with several presets helps this process with lot of options

Yes, babel-minify would be an alternative, but at the time of this writing it's considerabley slower than UglifyJS.

We however mention it as an alternative in the config. We haven't added it initially because the default setup of this template aims to compile to ES5 anyway, and when doing that, Uglify is as good in terms of minification and much faster - at least that's my latest information, feel free to correct me :)

Babel-minify doesn't do tree-shaking either.

(see also webpack-closure-compiler)

I don't think that the closure-compiler would be a good addition to this template - closure is a whole other beast of its own.

The above link has benchmark data (for react.js) with uglify, closure-compiler, betternut, closure-compiler-js and babel-minify

In those benchmarks, Uglify pretty much "wins" each of them, so I think we are good in that regard :)

many be this enhancement solve this issue

I don't think so - this is not a problem of tree-shaking or minification.

[CharlesKumar]

The benchmark data is for react.js

how much es6 modules react.js using may play a keyrole here

babel-minify has series of plugins to achieve the desired treeshaking

We however mention it as an alternative in the config. We haven't added it initially because the default setup of this template aims to compile to ES5 anyway, and when doing that, Uglify is as good in terms of minification and much faster - at least that's my latest information, feel free to correct me :)

yes sort of feature discussion to provide better options if we could find

[LinusBorg]

As far as I understand it, the only advantage concerning tree-shaking that babel-minify has is that it can also tree-shake unused classes.

But that only works if we don't transpile es6 classes to es5, which we don't want for our default setup.

[CharlesKumar]

performing code elimination via Babili, transpiling to es5 via Babel and finally minifying via UglifyJS

or tweaking uglifyjs options to do some unsafe operations [not recommended]

so its now seems to be a future request... we can get better options in the future

[LinusBorg]

I think this can be closed for now, we recently switched to the new uglify plugin which also can compress es6.