@vue/cli is currently using uglify-es via the webpack plugin for script minification.
However, regarding this comment, uglify-es is no longer actively maintained. This circumstance resulted in a fork, terser, especially to fix or at least work on the not-that-small amount of issues uglify-es had or still has (at least these).
A PR to swap out uglify-es in favor of terserresulted in a different plugin - terser-webpack-plugin.
Unless the maintenance of uglify-es surprisingly changes, I'd suggest to go with the maintained fork, especially since it has a better chance to get bugs fixed in a more reasonable amount of time.
The new plugin's API is almost equivalent, only uglifyOptions was renamed to terserOptions.
No new API; Current API unchanged as long as no one intercepts the minimizer configuration entry (it's currently not possible to just swap out the plugin options of uglifyjs-webpack-plugin via chaining).
Maybe babel-minify is a better choice?
Possibly - however, there are two aspects to take into consideration:
babel - even though it's already used in most cases, it is not required.babel-minify show that it is drastically slower, while resulting in only roughly equivalent bundle size (slightly larger is most cases): https://github.com/babel/minify#benchmarksuglify-js is still maintained. The package that is not published anymore is uglify-es. You should open an issue at uglifyjs webpack plugin to ask them to switch to the uglify-js package instead.
uglify-js is still maintained, yes - that's why I was talking about uglify-es, which does no longer seem to be maintained (regarding the comment linked above). Main difference is that uglify-js cannot properly minify scripts with using > ES5 - that's why uglifyjs-webpack-plugin is using uglify-es under the hood (since v1.0): It may handle both. Changing to uglify-js would remove the extended capabilities, so I don't think it's worth considering.
When using babel with a browser-based list of transforms (e.g. via preset-env) like @vue/cli offers, it is possible to be faced with resulting code that is not fully ES5-compliant and thus cannot be handled by uglify-js, so it'd be problematic to use it (obviously).
Let's keep this open for now, since we are not so sure about the stability of terser and how the fork itself will be maintained in the long run. Ultimately this is something uglifyjs-webpack-plugin needs to consider as well.
Just an update: It seems there are plans for webpack to use terser-webpack-plugin instead of uglifyjs-webpack-plugin as default minimizer.
Just an additional update - a PR for using terser-webpack-plugin instead of its (now again) uglify-js counterpart as default minimizer in webpack was merged two weeks ago:
https://github.com/webpack/webpack/pull/8036
However, if I've got that correctly, this will be part of v5, not a v4 release.
Most helpful comment
Let's keep this open for now, since we are not so sure about the stability of
terserand how the fork itself will be maintained in the long run. Ultimately this is somethinguglifyjs-webpack-pluginneeds to consider as well.