什么构成构建错误vs 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，这是作者唯一可以标记编译的东西。