与stats.compilation.errors或stats.compilation.warning相比，什么构成了构建错误？

Question

顺便说一下，我用Webpack 2- v2.1.0-beta.25

我试图向我的框架的用户提供有用的错误反馈，但我很难找出这三项之间的区别：

• 建置误差
• stats.compilation.errors
• stats.compilation.warning

构建错误似乎总是null，即使我故意添加错误。stats.compilation.errors输出我所需要的有用的错误，而stats.compilation.warning似乎没有输出我所能看到的任何东西。

我有一些代码来说明我的观点：

gulp.task('javascript', () => {
    return webpack(webpackConfig, (err, stats) => {
        if (err) {
            console.error('Failed to create a production build. Reason:');
            [err].forEach(er => {
                console.log(er.message || er);
                console.log();
            });
            process.exit(1);
        }

        if (stats.compilation.errors && stats.compilation.errors.length) {
            console.log(stats.compilation.warnings.toString());
        }

        if (stats.compilation.warnings && stats.compilation.warnings.length) {
            console.log(stats.compilation.warnings.toString());
        }
    });
});

谁能澄清一下不同之处吗？

Answer 1

编译器错误(不可恢复)

Webpack编译器错误是致命的、不可恢复的错误。Webpack在验证编译器选项时可能引发致命错误，或者在应用编译器选项时由插件引发致命错误：

class GandalfPlugin {
  apply() {
    throw new Error('THOU SHALL NOT PASS!')
  }
}

编译错误、警告(软)

这些问题主要是有趣的，而且发生频率最高。在内部，Webpack将webpack/tapable应用于所有需要执行某些工作的控制器对象。这包括编译器和编译实例。当插件实例被分配给编译器时，它们的大部分工作都是在编译过程中执行的。

一个不明显的地方是，这些都被视为软错误和警告。编译不受同步和异步错误的保护:编译总是成功地完成，有或没有错误(除非被困在无限循环中)，而且它永远不会破坏编译器。最终，所有的东西都被推到了compilation.errors上，实际上，这是作者唯一可用的东西来标记编译。