Webpack when to use `NoErrorsPlugin`?
Since the webpack documentation concerning this remains sparse, let's look at the source code, https://github.com/webpack/webpack/tree/master/lib/NoErrorsPlugin.js:
let deprecationReported = false;
class NoErrorsPlugin {
apply(compiler) {
compiler.plugin("should-emit", (compilation) => {
if(!deprecationReported) {
compilation.warnings.push("webpack: Using NoErrorsPlugin is deprecated.\n" +
"Use NoEmitOnErrorsPlugin instead.\n");
deprecationReported = true;
}
if(compilation.errors.length > 0)
return false;
});
compiler.plugin("compilation", (compilation) => {
compilation.plugin("should-record", () => {
if(compilation.errors.length > 0)
return false;
});
});
}
}
module.exports = NoErrorsPlugin;
Ignore the deprecation aspect for now. This code is a webpack plugin as documented here: https://webpack.js.org/api/plugins. It uses the event hooks should-emit
and compilation
, which are documented here: https://webpack.js.org/api/plugins/compiler/#event-hooks. I could not find the should-record
hook, but it seems to be about this: https://webpack.js.org/api/plugins/compilation/#record-compilation-records-.
So we can summarize: if there are errors, the plugin suppresses the emission of target code, and the "storing of info about the compilation". I verified this with a React app, by toggling the plugin in the webpack configuration and monitoring the time stamp of the output bundle.
About the deprecation: in the same GitHub directory, there is also a "NoEmitOnErrorsPlugin.js", which looks like "NoErrorsPlugin.js", only with no deprecation. So, if we want to suppress code emission, we should use the new plugin.
As stated, NoErrorsPlugin (now renamed to NoEmitOnErrorsPlugin) does not emit any assets to the build folder when there were errors during the compilation.
The answer from @Carsten Führmann is really good, but as the OP was asking about when to use this plugin, I would like to add that the most common use cases for this plugin were two:
- Avoid emitting the application's assets when compiling in production mode.
Regarding this first use case (production's build), from Webpack 4 on it not needed anymore as it comes enabled by default when running Webpack in production mode. (https://github.com/webpack/webpack/releases?after=v4.0.1)
- Using Hot Module Replacement feature
If you follow the latest basic configuration (https://webpack.js.org/guides/hot-module-replacement/), you will find that is not strictly needed, but for some other HMR setups (https://www.npmjs.com/package/webpack-hot-middleware) this plugin is very useful, as it will prevent emitting any asset (and therefore any updates) to the browser in case that the code is not compiling.
To answer when we have to answer why. This Medium article summarizes the why pretty well. Note that NoErrorsPlugin
(v1), NoEmitOnErrorsPlugin
(v2,v3) and optimization.noEmitOnErrors
(v4) are all manifestations of the same feature. The article discusses v4 but the why remains the same.
Why not to use NoErrorsPlugin
: working parts of the application cannot be used if any part has an error. In development, it can be tiresome to fix a messy part B if you just need to quickly test the new code of part A. Imagine building a car and you want to try how smoothly the trunk open but you cannot because the cat hood ornament is not in place.
Why to use NoErrorsPlugin
: no broken bundles. In production, you probably want all the parts of the application to be in a working condition because real risks are involved. An error anywhere in the app can compromise the functioning and security of the other parts. Therefore we do not want to publish those other maybe-functioning parts. We want to continue serving the old but stable version as a whole. If an error occurs in the build we do not want it to affect the stable version in any way. This is why to use NoErrorsPlugin
.
I was reading the answer, but still don't get it. Here is what I found.
webpack.NoErrorsPlugin() is an optional plugin that tells the reloader to not reload if there is an error. The error is simply printed in the console, and the page does not reload. If you do not have this plugin enabled and you have an error, a red screen of death is thrown.
Copy from here