webpack 构建失败：明显的依赖不匹配，如何解决？答案

【问题标题】：webpack build failing: apparent dependency mismatches, how to resolve?webpack 构建失败：明显的依赖不匹配，如何解决？
【发布时间】：2018-04-25 18:11:20
【问题描述】：

我正在将一个大型项目转换为 webpack，并且遇到了构建错误（实际上，不同的错误取决于我尝试解决的方式）。我对 webpack 还不是很熟练，希望能得到一些关于此类问题的典型解决方案的帮助。

某些依赖项之间似乎存在冲突：

"@babel/core": "^7.0.0-beta.42",
"@babel/preset-env": "^7.0.0-beta.42",
"backbone.radio": "2.0.0",

Webpack 抱怨：Cannot find module 'babel-preset-es2015'。看起来backbone.radio 有一个带有"presets": ["es2015"] 的.babelrc 文件，尽管它是一个依赖项，但babel 似乎试图兑现它，但它将babel-preset-env 列为devDependency，因此找不到。

好的，所以我尝试将 babel-preset-es2015@6.3.13（引用的同一个骨干网）显式安装为顶级依赖项，以便可以找到它。然后它找到了，但 webpack（或真正的 babel）抱怨：Error: Plugin/Preset files are not allowed to export objects, only functions.

很好，所以我尝试安装与 babel 7 兼容的较新版本的预设，并且希望与骨干网兼容。似乎名称已更改，因此我安装了@babel/preset-es2015@7.0.0-beta.42。当然名称不匹配，所以我添加了一个 webpack 别名，但这不起作用，仍然找不到；我想 babel 不会使用 babel 加载预设的依赖项，而是自己加载。

所以现在我被困住了。人们通常会做什么来解决这些问题？我尚未确定的其他潜在想法是可能的：

告诉 babel（不知何故？）将 babel-preset-es2015 别名为 @babel/preset-es2015？
配置yarn（不知何故？）以省略/删除backbone.radio的.babelrc文件（如果该文件消失，问题就完全消失了，但我当然不能一直手动从node_modules中删除它）李>

【问题讨论】：

你真的想在这个主干模块上运行 Babel 吗？通常最好只在你自己的代码上运行 Babel，所以我们建议将 exclude: /node_modules/ 作为 babel-loader 配置的一部分。
还有你使用 Babel 的不稳定测试版的原因吗？除非您需要某些特定功能，否则如果您使用稳定的 6.x 版本，则不太可能遇到问题。
@loganfsmyth 我没有想过将backbone.radio 从babel 转译中排除。排除所有 node_modules 是否可取？我假设很多模块都导出它们的源文件而不是转译文件，不是吗？此外，我们有可能从不稳定的测试版中恢复过来，但我希望一旦它退出测试版，我也会遇到同样的问题。我认为读取 babelrc 以获取依赖项的行为是预期的，而不是错误。
这实际上取决于您加载的依赖项以及它们各自的目标版本是什么。不加选择地编译所有 node_modules 将使您的前期构建时间大大增加。也就是说，如果你确实想编译 node_modules，Babel 的 beta 版确实有意义。

标签： webpack babeljs yarnpkg

【解决方案1】：

在 Babel 6 最初的生命周期中编译 node_modules 中的东西并不是一件真正的事情，所以它可能会很痛苦。直到最近，我们还明确建议用户在他们的 babel-loader 配置中设置 exclude: /node_modules/，因为在任意第三方代码上运行 Babel 过去和现在都有些危险。

对于您的具体问题，您有两种选择：

使用exclude: /node_modules/，以便 Babel 只处理您自己的代码。
升级到beta.46，因为我们现在添加了对Node 包概念的一流支持，这是我们以前没有的。 Babel >= beta.45 将只搜索“根”包中的.babelrc 文件。

我还要补充一点，如果你的 Babel 配置现在在 .babelrc 中，那不会影响 node_modules 中的东西，所以如果你打算编译第三方代码，你会想要移动将您的配置文件添加到项目根目录中的 babel.config.js 文件中，或者直接将其放入您的 webpack.config.js 中。您可能还希望将 sourceType: 'unambiguous' 作为 Babel 选项显式传递。

最后，如果您使用的是测试版，我们绝对仍在进行重大更改，因此您不应在 package.json 中使用 ^，因为这会让您使用最新版本的所有内容，我们与早期版本相比，可能已经损坏。

【讨论】：

你是说 babel 6 无论如何都不会在 node_modules 中转译任何东西，而转译这些东西的能力在 babel 7 中是新的吗？无论如何，这听起来像是要走的路。我们之前从 gulp 调用 babel 并且特别省略了 node_modules，但是我们在 requirejs 路径配置中明确列出了已知的转译代码。
不完全是，我的意思是 Babel 6 在编译 node_modules 方面非常糟糕，而 Babel 7 稍微好一点，并且可能会在未来的 beta 中得到更多改进。