快速体验
- 打开 InsCode(快马)平台 https://www.inscode.net
- 输入框内输入如下内容：
创建一个Monorepo项目，包含前端（React）和后端（Node.js）两个子项目。使用PNPM管理依赖，并展示如何通过PNPM的workspace功能共享公共依赖。生成一个脚本，自动安装PNPM，初始化Monorepo结构，并配置共享依赖。最后，提供一个简单的示例，展示如何在子项目中引用共享依赖。- 点击'项目生成'按钮，等待项目生成完整后预览效果
今天在重构公司一个中大型项目时，终于把 yarn 换成了 pnpm，整个过程比想象中顺利很多。特别想分享下在 Monorepo 项目中使用 pnpm 的实战经验，尤其是它如何优雅解决传统包管理工具的依赖地狱问题。
为什么选择 pnpm 管理 Monorepo之前用 yarn workspace 时，node_modules 经常出现幽灵依赖，不同子项目依赖版本冲突时调试起来特别痛苦。pnpm 的硬链接机制让所有依赖只安装一次，不仅节省磁盘空间，还能严格保证依赖树的一致性。实测在 CI 环境里，安装速度比 yarn 快了近 40%。
初始化 Monorepo 项目结构先全局安装 pnpm（用 npm 或 brew 都可以），然后创建项目根目录。关键是在根目录添加 pnpm-workspace.yaml 文件，这里定义了我们的两个子项目：packages/frontend（React）和 packages/backend（Node.js）。这种结构比 lerna 更轻量，不需要额外工具。
共享依赖的魔法在根目录执行 pnpm install 时，公共依赖会自动提升到顶层 node_modules。比如我们给两个子项目都装了 lodash，物理存储只有一份。通过 workspace: 协议，子项目可以像这样引用共享包："shared-utils": "workspace:*"，比传统的 file:../ 方式更规范。
前端项目的特殊处理React 项目需要特别注意 peerDependencies。pnpm 的严格模式会检查这些隐式依赖，我们通过在 .npmrc 添加 auto-install-peers=true 解决。另外 Vite 的优化依赖预构建，在 pnpm 下表现更稳定。
后端项目的依赖隔离Node.js 服务端用 pnpm 的 --filter 参数特别方便，比如只给 backend 安装 typeorm：pnpm --filter backend add typeorm。这种精准安装避免了前端不必要的依赖混入。
CI 环境优化技巧在 GitHub Actions 中缓存 pnpm 的 store 目录（默认在 ~/.pnpm-store），能让后续构建跳过依赖下载。我们还写了自动清理旧版本的脚本，防止 store 无限膨胀。
- 遇到的坑与解决方案
- 某些旧版 webpack 插件会因 pnpm 的符号链接报错，升级到新版即可
- Docker 构建时需要配置 --virtual-store 参数匹配宿主机路径
用 pnpm patch 命令临时修改第三方库比 fork 更高效
性能对比数据在 M1 Mac 上测试：
- 首次安装：pnpm 1分12秒 vs yarn 2分37秒
- 重复安装：pnpm 8秒 vs yarn 29秒
- 磁盘占用：pnpm 1.2GB vs yarn 3.8GB
整个迁移过程最惊喜的是 pnpm 的确定性安装——所有环境的 node_modules 结构完全一致，再也没出现过 "在我机器上是好的" 这种问题。对于需要同时维护多个关联项目的团队，这套方案确实能省下大量调试时间。
最近在 InsCode(快马)平台 上尝试创建 Monorepo 模板时，发现它原生支持 pnpm workspace，新建项目时自动生成正确的配置文件结构。最方便的是可以直接在线调试各个子项目的启动联动，不用反复切换本地终端。对于想快速体验 pnpm 工作流的同学，这种开箱即用的环境确实能少走很多弯路。
快速体验
- 打开 InsCode(快马)平台 https://www.inscode.net
- 输入框内输入如下内容：
创建一个Monorepo项目，包含前端（React）和后端（Node.js）两个子项目。使用PNPM管理依赖，并展示如何通过PNPM的workspace功能共享公共依赖。生成一个脚本，自动安装PNPM，初始化Monorepo结构，并配置共享依赖。最后，提供一个简单的示例，展示如何在子项目中引用共享依赖。- 点击'项目生成'按钮，等待项目生成完整后预览效果
