Webpack returns errors in two different ways - don't understand this API design

[robert-westenberger]

I'm looking at this piece of documentation

https://webpack.js.org/api/node/#error-handling

(err, stats) => {
    if (err) {
      console.error(err.stack || err);
      if (err.details) {
        console.error(err.details);
      }
      return;
    }

    const info = stats.toJson();

    if (stats.hasErrors()) {
      console.error(info.errors);
    }

    if (stats.hasWarnings()) {
      console.warn(info.warnings);
    }

    // Log result...
  }

i don't understand why errors are being exposed to the developer in two different ways. Am i alone in thinking this is strange? Is there some historical reason why there are two places a developer needs to check for errors?

[alexander-akait]

Because you can have two different types of errors:

• Cirical errors, when compilation failed and webpack can't generate bundle, for example - you don't have access to write something in the dist output directory
• Basic errors in modules/plugins/loaders, i.e. compilation was finished but with some errors, they are not critical and webpack generates output and we can output details of errors, for example - you are importing a non-installed package or some postcss plugin can do something but still render a CSS file

[robert-westenberger]

Makes sense - thanks