背景
之前有写过几篇关于Monorepo的文章，具体如下：
再次复习一下MonoRepo的概念：
Monorepo是包含多个不同项目的单一存储库，且不同项目之间具有明确定义的关系。
之前大多数是理论知识，能让我们知道pnpm 和nx 是什么，但是具体要到项目实战就有点懵，不知道从而下手，下面我们就一步步开始搭建pnpm+nx的Monorepo仓库。
PS：这里将会从已有项目中去开始踩坑，这里用的是之前做一个node-gptcommit命令行工具+一个chrome插件，将两个项目放到一个Monorepo仓库去管理。
项目初始化
第一步，项目结构调整
先来看看原先node-gptcommit 项目结构：
node-gptcommit ├── bin | └── ngptcommit.js ├── dist | ├── ... ├── src | ├── ... ├── test | ├── ... ├── jest.config.js ├── babel.config.js ├── package.json ├── pnpm-lock.yaml ├── rollup.config.ts ├── tsconfig.json └── tslint.json ├── README.en.md ├── README.md
再看一下node-gptcommit-chrome项目的目录结构：
node-gptcommit-chrome ├── dist | ├── ... ├── src | ├── ... ├── test | ├── ... ├── index.html ├── package.json ├── public ├── tsconfig.json ├── tsconfig.node.json └── vite.config.ts ├── README.md
接下来我们把项目结构做一下调整，将两个项目的代码挪到packages目录下，同时在新项目中初始化npm init ，大概结构如下：
node-gptcommit ├── apps # 应用层 | ├── chrome-extension # chrome插件 | | ├── ... | └── node-cli # 命令行工具 | ├── ... ├── libs # 封装好的lib库 | └── summarize # 总结AI客户端 | ├── ... ├── README.md ├── package.json
第二步，项目初始化
前提条件准备：
- 安装全局
pnpm - 升级node版本到16.19.0+，这里可以通过pnpm去管理node版本
# 先安装全局pnpm 后续需要根据pnpm + workplace去管理 npm install pnpm -g # 切换node版本 pnpm env use --global 16
2.1 创建pnpm workplace
1.新建pnpm workplace工作空间文件pnpm-workspace.yaml ，具体如下:
packages: # 会将packages下面归纳给到pnpm工作空间进行管理 - 'packages/*' # 排除下面的目录 - '!**/test/**'
2.子项目互相依赖的时候，可以通过workplace: 协议去设置依赖，支持一下几种写法：
“npm_name”: “workplace: *”所有版本都依赖本地工作空间“npm_name”: “workplace: npm_name@1.0.0”指定版本写法“npm_name”: “workplace: ../npm_name”相对路径写法
因此apps 中的应用层加入对公共库libs的依赖，如在apps/node-cli 将
{ ... "dependencies": { "@node-gptcommit/summarize": "workplace: *", ... } ... }
3.子项目中需要对package.json 中的scripts 中做统一管理，如下：
{ ... "scripts": { "build": "xxx", //按照各自的项目填写对应的构建脚本 "dev": "xxx", "test": "xxx" }, ... }
2.2 引入nx，实现按序打包
1.全局安装和在项目根目录下安装 nx
# 全局安装方便后面调试项目使用 pnpm install nx -g # 项目nx初始化 注意目录不能已经安装nx或者有nx.json npx nx@latest init # 官网里 npx nx@latest init 一直有问题，回头去定位看看
nx在monorepo 架构中里主要解决几个问题：
- 解决项目中互相依赖问题，就是构建顺序问题，其任务流有点像管道的概念
- 解决项目中打包缓存问题，比如：一些公共包没有多大变动，就不需要再次打包
- 提供一些快捷工具快速引入一个子项目或公共包
还需要转变一个观点：
重要提示：nx会接手项目的所有打包流程，因此所有相关的命令都由nx进行触发
2.自动生成的 nx.json 解析认知 ，
{ "workspaceLayout": { // 工作空间配置 "appsDir": "apps", // 应用层文件夹 "libsDir": "libs" // 公共库文件夹 }, "targetDefaults": { // 统一的配置项，用于覆盖每个项目中的project.json配置 "build": { // 统一构建选项 "dependsOn": ["^build"], // 当构建的时会自动将依赖的其他子项目也进行构建build "inputs": ["production", "^production"] // 构建 } }, "tasksRunnerOptions": { // 任务执行器选项 "default": { // 默认的任务执行器的选项 "runner": "nx/tasks-runners/default", // 任务执行器 "options": { "parallel": 5, // 构建并发线程个数 "cacheableOperations": ["build", "lint", "test"] // 可缓存的操作 } } } }
nx.json 主要用来配置子项目的构建顺序和控制缓存，比如：
- 构建顺序：在项目中
apps进行build操作时候会依赖libs项目中的build，就可以在targetDefaults中配置"dependsOn": ["^build"]，举个例子：
- 当
apps的子项目node-cli在运行build操作 - 会提前将依赖的
libs中的summarize子项目也进行build
- 控制缓存：提高构建速度，利用缓存，但是有时候我们并不需要每个构建命令都去缓存，这个时候就可以用
tasksRunnerOptions中的cacheableOperations去控制
nx.json 的其他详细配置可以到官网中查看nx.json。
3.调整根目录package.json中scripts，后续将采用nx去进行分发构建任务：
{ ... "scripts": { "build": "nx run-many --target=build", "dev": "nx run-many --target=dev", "test": "nx run-many --target=test" }, ... }
4.nx一些命令工具，如使用nx graph 可以看到Monorepo中子项目相互依赖情况，如下图所示：
更多使用命令，可以到官网查看：nx命令脚本
总结
到了这里，我们完成Monorepo基本架构的搭建，后续工作就依据不同的业务或代码进行重设计代码结构。
Monorepo架构有个很明显好处，就当你的项目需要新增一个子项目或者依据现有的功能进行剥离成功公共组件，将会很轻松就实现。比如说，当我的node-gptcommit需要新增一个桌面端，那么我就可以根据现有的libs库快速开发完成。
在pnpm+nx 搭建Monorepo项目中，我们可以学习到几个点：
- 使用
pnpm替代yarn或npm管理node_modules，不仅快，而且会比较稳定，因为它不允许代码引入一些未在package.json使用的npm包 - 使用
pnpm同时支持一些libs被其他apps的子应用依赖，如:"@node-gptcommit/git-utils": "workplace: *” nx在使用上会需要一些门槛，尤其需要理解其中几个点：
- 第一，子项目互相依赖，
nx可以在build构建的时候将另外一个包也同时build构建 - 第二，
nx会取代掉我们平时在根目录使用yarn build或npm build的习惯，而是采用nx build - 第三，
nx提供一些常用的命令行，如：nx graph能让我们快速解决Monorepo架构常见的依赖问题
本博文项目Github源码地址： node-gptcommit
