我正在尝试了解为 NodeJS/React 项目构建 monorepos 的最佳实践。
我需要:
React SPA 与服务器端渲染。
后端有 Express、MongoDB、mongoose 模块等。
一些实用函数、助手、枚举等的共享(通用)模块;
用 monorepo 构建这种架构的优雅方式是什么(我将使用 Lerna)?
- 我应该将 API 和 SSR EXpress 服务器分开吗?
- 如果是,我应该将 React 前端代码与 SSR 服务器分开吗?
- 如何配置 webpack 开发环境,以便开发期间的其他模块始终获得“共享”模块的转译 (Babel) 版本(这个问题有点超出范围,只是解决方案可能很简单)
我知道答案主要是“视情况而定”,但我需要适用于许多情况的通用方法,即使它会有点过度设计。
谢谢
嗯,是的,主要取决于 :)。但是,我刚刚用我自己的代码库完成了这个转换,所以希望我能提供一些帮助。我最近使用 lerna 将 RMWC 从一个单一的 repo 转换为多个包。 https://jamesmfriedman.github.io/rmwc/
我的回答会做出以下假设:
- 你正在单独发布你的包(因此 lerna)
- 因此,您的各个包都很好地组件化并且具有很好的关注点分离
- 您正在 npm 上的一个范围组织下发布您的包(我的是 @rmwc)。这不是必需的,但这个特殊的设置让我完成了一些有趣的 webpack hacks。如果您的公司使用私有(private) npm,这也是您所拥有的。
有一个 Base/Core/或者 Utils 模块
引用:https://github.com/jamesmfriedman/rmwc/tree/master/src/base
这是一个包含所有或大部分其他模块所依赖的通用工具的单一模块。一般的经验法则,如果有多个包需要它,请将其拉出到您的基本模块中,以便对其进行正确的版本控制和共享。这也将防止将来代码碎片化,因为当您更新基本模块代码时,您将需要重构使用它的组件。
是的,分开你的SSR代码
这只是很好的关注点分离。如果你仔细想想,React 是同构的,所以你的组件并不真正关心它们在哪里被渲染。如果没有关于您的代码库或您正在解决的问题的更多详细信息,我的直觉会告诉我只做一个额外的 SSR/服务器包。从依赖的角度来看,这也是有道理的。您的任何组件都不会依赖这些包,但这些包将依赖您的所有组件。
决定包分离的部分原因还与可能经常更改和不经常更改的内容有关。同样,高度依赖于您的问题,但如果您的服务器或 ssr 包只负责渲染和水合组件,则它们可能不会经常更改。
我没有这方面的 1:1 引用,但我的项目中关闭的东西可能是重新导入我所有其他组件的根 rmwc 模块。 https://github.com/jamesmfriedman/rmwc/tree/master/src/rmwc
Webpack 魔法
Lerna 包含一个名为“bootstrap”的方法,它可以神奇地安装所有依赖项并将一堆目录符号链接(symbolic link)在一起。如果您使用的是 Typescript 或 Flow,符号链接(symbolic link)可能会导致问题或根本不起作用。对我来说,我创建了一个路径别名作为解决方法。
https://github.com/jamesmfriedman/rmwc/blob/master/config-overrides.js#L38
基本上,每当引用@rmwc(我的 npm 范围)时,我都会将 webpack 重定向到我的 src 文件夹。这是我受益于将它们全部置于同一范围内的地方。如果有不同的范围或包名称,您仍然可以使用以下技巧,只需指定多个别名即可。
我遇到的其他问题
释放!这不是直截了当的。每个包都有自己的必须部署的 dist 文件(构建的 es5 代码)。解决方案,运行 lerna version
而不是 lerna release
。这使得 lerna 不运行 npm 发布步骤。然后你可以在你的每个包中有一个自定义的发布脚本。 https://github.com/jamesmfriedman/rmwc/blob/master/config-overrides.js#L38
版本控制:不要做独立版本。我只有轶事推理,但这让事情变得更加困惑,更难跟踪你的包的演变。毕竟,即使它是单独发布的,它仍然是一个单独的项目,因此看到版本号一起移动是有意义的。
将您的主 package.json 文件与您的所有脚本一起保存在根目录中,并尽可能减少其他包。考虑到我的项目规模,我所做的任何更改都会乘以 38 个组件。
狩猎愉快,希望对您有所帮助!