Tim的资源站使用 Webpack 的过程中可能会出现各种运行时警告或错误。通常，都是由于某种原因导致了特定部分的构建失败。我们可以使用下面列出的基本过程来开排查问题：
- 将
--display-error-details标志传递给 Webpack 以获得更准确的错误信息。示例：npm run build -- --display-error-details。 - 仔细推敲错误的根源。有时您可以推断出上下文有什么问题。如果 Webpack 无法解析模块，它可能不会像您期望的那样把模块传递给 loader。
- 尝试了解错误的来源。它来自您的代码、依赖项，还是 Webpack？
- 删除代码直到错误消失再添加代码，直到它再次出现。通过隔离的形式将问题尽可能的简化。
- 如果代码在另一个项目中工作，那么找出不同的东西。项目之间的依赖关系可能会有所不同，或者设置会有所不同。在最糟糕的情况下，你依赖的包可能回退了版本。出于这个原因，使用 lockfile 是一个好主意。
- 仔细研究相关的包。有时候查看 package.json 文件可以发现一些更深入的信息。有可能，您正在使用的包无法按预期方式解析。
- 在线搜索错误，也许其他人遇到过它。Stack Overflow和官方 issue tracker 是比较好的在线途径。
- 启用
stats: "verbose"以从 Webpack 获取更多信息。官方文档介绍了更多的相关信息。 - 在错误附近添加临时
console.log以更深入地了解问题。还有一个更重量级的方式，通过 Chrome Dev Tools 调试 Webpack。 - 在 Stack Overflow 上提问或使用官方 Gitter 频道。
- 如果上述方法都无济于事并且您确信您发现了 bug，请在官方 issue tracker 或其他适当位置报告问题。另外，请仔细遵循问题模板，并提供最小的可运行示例，因为它有助于解决问题。
有时通过搜索引擎搜索错误提示信息并以此方式获得答案是最快的。除此之外，上面是一个很好的调试顺序。如果您的设置过去有效，您还可以考虑使用 git bisect 之类的命令来确定已知工作状态和当前已损坏工作状态之间的变化。
接下来，您将了解一些最常见的错误并学习如何处理它们。
找不到 Entry 模块的错误
如果入口模块的路径不存在，则最终可能会出现此错误。该错误消息告诉您，Webpack 无法找到的路径。
ERROR… 未找到模块
该错误可能出于两个原因。loader 定义存在问题，使其指向一个不存在的加载器，或者通过代码导入路径错误，使它指向了不存在的模块。错误消息指出了要修复的内容。
模块解析失败
即使 Webpack 可以很好地解析你的模块，它仍然无法构建它们。如果您使用的是 loader 无法理解的语法，则可能会发生这种情况。您可能在处理过程中遗漏了某些内容。
找不到 loader
还有另一个微妙与 loader 相关的错误。如果一个包与一个 loader 的名称匹配上了，但是却没有实现 loader 接口，此时 Webpack 会匹配它们并抛出一个错误：这个包不是 loader。
这个错误可能是由于 loader: "eslint" 之类的写法造成的，正常情况应该是 loader: "eslint-loader"。如果 loader 根本不存在，则会引发错误 Module not found。
模块构建失败：Unknown word
此错误与上一个错误类似。解析文件成功，但有未知的语法。很可能问题是拼写错误，但是当 Webpack 正常导入并遇到它不理解的语法时，也会发生此错误。这很可能意味着该特定文件类型缺少相应的 loader。
SyntaxError：Unexpected token
SyntaxError是上述类别的另一种错误。如果您使用尚未与 terser 一起编译的 ES2015 语法，则可能出现此错误。当遇到它无法识别的语法结构时，就会引发这个错误。
DeprecationWarning
尤其是在 Webpack 更新为新的主要版本之后，Node 可能会抛出这个错误。您正在使用的插件或 loader 可能需要更新。通常所需的更改很少。请通过 Node 运行 webpack : node --trace-deprecation node_modules/.bin/webpack --env production，以找出警告的来源。
将 --trace-deprecation 标志传递给 Node 非常重要，这样可以查看警告源自何处。使用 --trace-warnings 是另一种方式，它将捕获所有警告的跟踪信息，而不仅仅是过时信息。
总结
这些只是错误的例子。一些是因为 Webpack 方面发生了特定错误，但其余错误来自 loader 和插件。简化您的项目是一个很好的步骤，因为它可以更容易地理解错误发生的位置。
在大多数情况下，如果您知道了错误发生的位置，错误很快就会解决。最坏的情况是，您使用的工具本身除了问题。在这种情况下，您应该向该工具项目提供高质量的报告并帮助解决它。
