Question

我将从描述上下文开始，我希望理想的情况是什么，到目前为止我已经尝试过。

上下文

我正在尝试使用Webpack构建简单的React应用程序。我将此应用程序称为核心。最重要的是，Webpack可以捆绑一个可选的 branding ，它可以查看给定的品牌目录，使用自己的加载程序和输出策略来获取资产并转换自定义SASS。然后，它会用品牌专用资产（例如收藏夹图标，徽标，背景）覆盖核心使用的默认资产。

结构如下：

我有几个webpack配置文件，

webpack.dev.js -指定env和dev-server配置的配置，并将其与核心和品牌合并
webpack.prod.js -指定env和缩小插件的小型配置，并将其与核心和品牌合并
webpack.branding.js -声明品牌特定的捆绑规则并与通用合并
webpack.core.js -声明特定于核心的捆绑规则并与通用合并
webpack.generic.js -提供品牌和核心用途的通用配置

当前情况下这些文件的来源可以在this gist中找到。

理想情况

使用默认资产，Core应该能够完全独立运行。在开始开发/产品构建过程时，除非专门要求专门运行一个，否则它将同时运行核心和品牌。

品牌还应该能够自己建立，从而形成一个仅包含品牌资产的小包装。该过程应足够灵活，以使品牌发行dist应该能够替换dist核心文件夹中的任何文件，而核心不必重新编译和重建引用。目前，这些资产仅限于CSS文件（branding.css）和某些图像资产。

我尝试过的事情

我尝试使用内置Webpack multicompiler来同时运行核心和品牌（module.exports = [core, branding]），但是我无法确定Webpack运行以下命令的顺序核心和品牌流程，因为它可以并行运行它们。由于品牌化过程要小得多，因此总是会先完成，从而导致品牌资产默认被覆盖。
我尝试使用webpack-merge合并核心配置文件和品牌配置文件，但这不起作用，因为我为两者指定了不同的输出规则。 Core在其输出命名约定中使用内容哈希，而品牌则不使用。尝试合并在一起时，效果不佳。使用merge.multiple()时，我将得到每个文件中的两个，一个使用哈希，一个不使用哈希，或者使用merge.smart()时，我将仅获得一个配置所指定的每个文件中的一个，无论是使用哈希还是不使用哈希（取决于合并顺序）。
我尝试使用&&命令（"build": "webpack --config webpack.core.js && webpack --config webpack.branding.js --branding <brand>"）从npm脚本中依次运行核心和品牌。不能与webpack-dev-server协同工作。

在此先感谢您的帮助和/或建议。如有必要，我将用更多信息更新我的问题。

Answer 1

我知道这不是您问题的直接答案，但我将其保留在此处以帮助其他人解决与表面上看起来完全相同的问题：

我思考我遇到了完全相同的问题，因为我的“ app”配置（使用DllPlugin引用其“ lib”捆绑包）失败了，因为其“ lib”依赖项的DLL清单尚未生成。这使我认为配置可能是并行运行的，而不是像webpack文档所说的那样顺序运行（这感觉很奇怪，但有时确实会发生错误）。

但是（我认为我的两个配置位于单独的文件中这一事实使情况更加恶化），我未能立即注意到一个重要的细节：实际的配置本身会立即加载，不是是时候建造了。因此，我的DllReferencePlugin配置尝试在运行任何配置之前立即加载DLL清单：

new webpack.DllReferencePlugin({
  manifest: require(path.join(tempDir, "/lib.dll-manifest.json"))
}),

幸运的是，manifest选项允许传递路径，而不是预加载清单对象。使用绝对路径允许DllReferencePlugin仅在配置运行时加载清单：

new webpack.DllReferencePlugin({
  manifest: path.join(tempDir, "/lib.dll-manifest.json")
}),

回想起来，这是一件很小的，“显而易见的”事情。但是在大型webpack配置中很容易错过。

因此，如果您遇到类似的问题，则可能是因为依赖项的webpack配置需要太早的内容，而依赖项才有机会自己生成文件。使用node的--inspect-brk和调试器（VS Code）进入构建脚本和webpack配置，这有助于我找到根本原因。

顺便说一句，我也看到了name和dependencies配置选项的提及，但是在文档中找不到关于它们的太多（如果有的话）信息：

const configA = {
  name: "lib",
  entry: ...
  ...
}

const configB = {
  name: "app",
  dependencies: ["lib"]
  entry: ...
  ...
}

This和this证明该功能存在，即使在文档中未提及。 ~~尽管我没有测试过，但您也许可以通过这种方式定义所需的构建顺序。~~最后，看来这也是难题的重要组成部分。没有name和dependencies属性，似乎webpack假定它可以并行运行配置，至少从webpack 4.25.1开始。

依次执行Webpack捆绑器

1 个答案: