如何管理具有许多独立小部件的大型 React/Redux 项目

Posted 2023-02-21

【中文标题】如何管理具有许多独立小部件的大型 React/Redux 项目

【英文标题】：how to manage a big React/Redux project with many independent widgets

【发布时间】：2016-05-05 00:58:21

【问题描述】：

我想要一个这样的项目结构：

./app/package.json
./app/src/index.js

./widget1/package.json
./widget1/src/index.js

./widget2/package.json
./widget2/src/index.js

./widget3/package.json
./widget3/src/index.js

你可以猜到，这个项目就像 NPM 小部件子项目的聚合，而应用程序src 文件夹是真正的应用程序，它使用不同的小部件子项目。

我希望在小部件之间进行清晰而严格的分离，因为我目前的经验告诉我，即使我告诉他们不要，开发人员也倾向于在小部件之间引入不需要的循环依赖关系。

在实践中，所有这些小部件都是 ReactJS 小部件，其中大多数都有 3 个常见的 JS 库：React、JQuery 和 Lodash。有些不需要这 3 个库，有些则需要额外的库，如 packery、react-slick 或 react-date-picker 所有这些小部件还应共享通用测试库，如 mocha。 他们绝对需要共享完全相同的通用库版本（因为显然我不希望在我的项目中使用不同版本的 React，也不想增加我的包大小）。

例如， - widget1 可能是一个 DatePicker 小部件，它依赖于 React + Lodash + react-date-picker（npm lib，不是我的） - 应用程序项目可能依赖于 React + Redux + Normalizr + 所有小部件及其传递依赖项，例如 react-date-picker

所有小部件都将是Presentational components，并且不需要更多花哨的依赖项。有些将只依赖于 React。有些可能有 Redux reducer，但由于它是普通的旧 JS 代码，不需要依赖。

小部件的数量可能很大，我不想在每次库更新时编辑 200 个 package.json 文件（但我最终可以使用一些代码来处理）。

在widget1/src 内部时，应禁止要求来自widget2 的代码。如果一个小部件必须能够依赖另一个小部件，则必须在客户端小部件的 package.json 中显式设置此依赖关系。

我应该能够使用 Webpack 构建并独立测试所有小部件。我还应该能够同时构建和测试整个项目，包括所有子项目，并拥有一份汇总的全局测试和代码覆盖率报告。

我不希望它给开发者带来糟糕的体验。 React 和 Webpack 允许重新加载热代码。如果我的浏览器中有真正的应用程序并且我修改了小部件的代码，我应该能够通过react-hot-loader 实时看到更改，而不必运行 npm 命令或按 F5。

---

我寻找的是相当于 Java Maven 的 dependencyManagement 系统，您通常在父 POM 中为所有子项目设置版本，并且版本以某种方式继承给所有子项目。所有子项目都不能互相看到（除非添加了显式依赖项），但它们可以说它们依赖于父项目中声明的库。所有的lib版本号都可以在父项目中设置。

---

是否可以使用 NPM 和 Webpack 做到这一点？

或者至少是接近它的东西？

谢谢

【问题讨论】：

使用 just npm 和 webpack？从技术上讲，是的。但是，您必须自己编写很多管道。毕业到 gulp 来管理所有这些任务，你可能会更好（并且可能有 gulp 插件可以帮助你）。

@rossipedia 我已经在使用 gulp 这不是问题

【参考方案1】：

您可以将每个小部件放在它自己的 git repo 中，并通过 repo URL 使用 NPM 安装它们。只要每个小部件定义了它们在自己的 NPM 包中使用的库，当它们在主项目中使用时，NPM 就会为您处理所有依赖项。

根据您团队的规模，您还可以注册 NPM 的私有包并将它们托管在那里https://www.npmjs.com/npm/private-packages

【讨论】：

这不允许只设置一次版本号（但我可以处理）。您确定此工作流程允许一次测试所有项目，并支持热重新加载而无需键入 npm publish 或其他任何内容吗？此外，我不太喜欢管理 200 个单独的 git 存储库，因为我希望小部件和应用程序同时发布（即具有相同的 git 版本标签）。

关于测试，我会为每个小部件创建一个规范来测试小部件自身的功能，然后在主项目中进行额外的测试来测试它们的集成——也许是矫枉过正？小部件的热重载不起作用，它们托管在某个服务器上，无论是 Github 还是 NPM。如果有 200 个小部件，为什么不在应用内有一个小部件目录并将它们开发为组件？

如果您在运行测试配置和 wepack 配置中允许热重载和测试，它将起作用

【参考方案2】：

你可能想试试https://github.com/n8tz/layer-pack， 因为它满足了提到的许多需求

它允许：

在 1 个源代码树中继承多个 npm 包

管理模块继承（驱动节点和webpack很好地解决它们）

将所有 Webpack conf 和配置文件放在一个共享、可继承和版本化的包中

等等……

请注意，使用太多继承包进行热重载可能会很慢。

另一种方法是使用您的小部件的预编译版本并将它们的部门外部化。