A simple monorepo demo supported by pnpm
See structures in pnpm-workspace.yaml
- 跨项目编译问题。一般来说一个项目只允许编译自己文件夹下的文件,但是在 monorepo 条件下会有很多"外部"包。有些 cli(比如项目中使用到的 nextjs)会提供类似的配置,如果没有的话可以通过 webpack 等的配置将 monorepo 内的包 include 进去
- 集体发布时的编译优化(未完成)。由于依赖提升的存在,我们应该很容易可以将一些公用的依赖提前编译好,防止重复编译占用资源和时间。
- 配置提升(未完成)。将比如 eslintrc/tsconfig 等配置文件提升,让各个 package 主动 extend 这些配置,实现配置的统一,有利于约束代码风格,也避免了重复配置这些文件。
# dev
pnpm run dev:next-app
And you can see a simple page with a clock provided by @demo/clock
举个例子,我们的 Layout 组件被三个项目共用,同时因为是一个业务组件,可能会跟着迭代进行开发。当我们有两个环境:dev 和 fat 时,这时候要求在 fat 上修改代码,我们至少会在两个分支上 commit 代码。 这时候为了保证 fat 不被 dev 影响,fat 我们需要发布一版 Layout,dev 我们也需要发布一版 Layout。同时用到 Layout的项目里,fat 和 dev 两个分支需要安装的 Layout 版本也不一样,这就造成了维护上的困难。
这个问题在 monorepo 里可以很好的解决,因为 monorepo 整体才会分dev和fat环境,对于子 repo 他们是没有自己的版本的,所以不存在需要发两次包,安装两次的困扰。 同时 monorepo 理论上可以优化构建,比如在集体发布的时候,我们可以先构建好每个项目都会用到的第三方包,如:react,react-dom 等,给各个子项目的构建结果使用,减少整体构建时间。 另外我们也可以更方便地抽离业务组件/业务模型,代码维护不再分隔到各个 repo 内,而是实现高度的复用。
关于现代包管理器的深度思考——为什么现在我更推荐 pnpm 而不是 npm/yarn?
下面是 pnpm 自己跑的 benchmark
另外 lerna yarn 的 monorepo 方案学习成本比较高,不如 pnpm 来的方便