uglifyjs-webpack-plugin is deprecated and should be replaced with terser-webpack-plugin in any modern build. The plugin's own GitHub repository is marked deprecated, and it depends on uglify-es, a minifier that is no longer maintained. If you are starting a project today or auditing an old one, uglifyjs-webpack-plugin is a dependency to remove, not to configure. This post explains what the plugin did, why it fell out of maintenance, and exactly how to migrate.
What the Plugin Did
uglifyjs-webpack-plugin was webpack's official wrapper around UglifyJS, the long-standing JavaScript minifier. Its job was to shrink production bundles by removing whitespace, shortening variable names, dropping dead code, and applying other size optimizations. For years it was the default minimizer in the webpack ecosystem, and you'll still find it referenced in older tutorials and copied into legacy webpack.config.js files.
The problem is that the JavaScript language moved and the underlying minifier didn't keep up cleanly.
Why It Was Deprecated
The original UglifyJS (uglify-js) did not support ES6+ syntax. To handle modern JavaScript, a separate branch called uglify-es was created. That branch then stopped being actively maintained. As the webpack team put it, uglify-es is no longer maintained and terser is a fork that incorporated a number of fixes and test cases that were left to go stale in the original project.
The community consolidated around terser, and webpack made terser-webpack-plugin the built-in minimizer starting in webpack 5. So the deprecation isn't a style preference — it reflects that the code path underneath the old plugin was abandoned.
The Security Angle
An unmaintained dependency is a standing risk for a simple reason: when a vulnerability is found, nobody ships a fix. The uglify-js lineage has a documented history of denial-of-service issues in its parser. CVE-2015-8858, recorded in the NVD, describes a regular expression denial of service (ReDoS) affecting uglify-js before version 2.6.0, where crafted input passed to a parse call could cause excessive CPU consumption. There was also CVE-2015-8857 concerning improper handling of boolean expression rewriting in versions before 2.4.24, though that entry has a messier publication history.
The specific old CVEs matter less than the pattern. A minifier processes code, and code processors that mishandle pathological input are a classic ReDoS surface. On a maintained project like terser, a newly reported issue gets triaged and patched. On a deprecated plugin sitting on top of an abandoned fork, it does not. That is the real reason to migrate: you are choosing a dependency that still has someone at the wheel.
How to Migrate to terser-webpack-plugin
The migration is straightforward. First, remove the old plugin and install the replacement:
npm uninstall uglifyjs-webpack-plugin
npm install terser-webpack-plugin --save-dev
Then update your webpack config. The main gotcha is that the options key changed from uglifyOptions to terserOptions. A typical before-and-after:
// Before: uglifyjs-webpack-plugin
const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
module.exports = {
optimization: {
minimizer: [
new UglifyJsPlugin({
uglifyOptions: {
compress: { drop_console: true },
},
}),
],
},
};
// After: terser-webpack-plugin
const TerserPlugin = require('terser-webpack-plugin');
module.exports = {
optimization: {
minimizer: [
new TerserPlugin({
terserOptions: {
compress: { drop_console: true },
},
}),
],
},
};
If you are on webpack 5, there is an even simpler path: terser-webpack-plugin ships out of the box, so in many projects you can delete the explicit plugin entirely and rely on the default minimizer. You only need to declare it explicitly when you want to customize terserOptions.
Most compress and mangle options carry over with the same names because terser began as a fork of uglify-es, so migrations are usually a rename plus a package swap.
Catching Dependencies Like This Automatically
uglifyjs-webpack-plugin is the kind of dependency that quietly rots in a package.json for years — it still builds, so nobody looks. The way to stay ahead of it is to scan your dependency tree for deprecated and vulnerable packages as part of CI, not during an occasional manual audit. A software composition analysis step can flag a package that has known CVEs or that npm reports as deprecated, so the warning shows up in a pull request instead of a post-incident review. For a walkthrough of picking such a tool, our guide on the package vulnerability scanner covers what to look for.
FAQ
Is uglifyjs-webpack-plugin still maintained?
No. The plugin's GitHub repository is marked as deprecated, and its underlying minifier, uglify-es, is no longer maintained. The maintained successor is terser-webpack-plugin, built on the actively developed terser minifier.
What is the difference between UglifyJS and Terser?
Terser is a fork of uglify-es created after that project stalled. It supports modern ES6+ JavaScript, incorporates fixes and test cases that were never merged upstream, and remains actively maintained. Its option names largely mirror UglifyJS, which makes migration easy.
Do I need any minifier plugin in webpack 5?
Not explicitly for basic minification. Webpack 5 includes terser-webpack-plugin as its default minimizer in production mode. You only need to add it to your config when you want to override the default terserOptions.
Is uglifyjs-webpack-plugin a security risk?
Its main risk is being unmaintained: the uglify-js lineage has documented ReDoS vulnerabilities such as CVE-2015-8858, and a deprecated package will not receive fixes for newly discovered issues. Migrating to a maintained tool like terser is the safe choice.