1. 从多仓库的泥潭中解放为什么企业级前端需要 Monorepo不知道你有没有经历过这样的场景公司里同时维护着五六个前端项目每个项目都长得差不多用的技术栈也类似但就是各自为政。你发现了一个公共组件的 bug需要改一个utils包结果你不得不跑到 A 项目的仓库里改一次提交、发版然后再跑到 B 项目的仓库里手动更新依赖版本再测试一遍。这还没完C 项目用的还是老版本你得去说服那个项目的负责人升级。光是沟通协调的时间就比写代码的时间还长。这就是传统MultiRepo多仓库模式下的日常团队规模越大业务线越多这种痛苦就越是成倍增长。MultiRepo 就像一个个独立的“小王国”初期确实简单清晰。但随着业务膨胀问题接踵而至代码复用变成了复制粘贴导致同一段逻辑散落在各处修个 bug 要打无数个补丁依赖版本四处飘散项目 A 用 React 18项目 B 还用着 16中间隔着一个大版本想统一升级那是一场牵一发而动全身的噩梦开发体验支离破碎每个项目都要配一遍 ESLint、Prettier、Jest构建配置也各有各的“祖传”写法新人上手得先熟悉好几个不同的“配方”。而Monorepo单一仓库提供的是一种“大一统”的解决方案。它把所有的项目、共享的包、工具配置都放在同一个代码仓库里管理。想象一下这就像一个大型超市所有商品代码模块分门别类地放在不同的货架上但它们共享同一个库存系统版本控制、同一套收银流程构建工具。你需要一个共享的按钮组件直接从packages/ui货架上拿所有用到它的应用立刻就能拿到最新版。这种模式带来的核心优势正是企业级开发所渴求的一致性、可维护性和开发效率的质变。不过光有 Monorepo 的概念还不够就像给你一块地告诉你这里能盖摩天大楼但没给你图纸和起重机。我们需要一套强大的工具链把蓝图变成现实。这就是pnpm和Turborepo这对“黄金搭档”登场的时候了。pnpm 负责解决依赖管理的混乱与磁盘空间危机而 Turborepo 则负责让整个仓库的构建和任务执行快如闪电。它们俩的结合才是构建一个健壮、高效的企业级前端工程体系的基石。2. 基石之选为什么是 pnpm Turborepo市面上包管理器和构建工具那么多为什么偏偏是它俩这可不是随便选的而是它们在 Monorepo 这个特定场景下用实实在在的优势拼出来的。2.1 pnpm为 Monorepo 而生的包管理器你可以把 npm 或 yarn 想象成传统的复制粘贴。安装lodash时它们会在每个项目的node_modules里都复制一份lodash的代码。如果有 10 个项目你的硬盘上就有 10 份一模一样的lodash。而pnpm的做法聪明得多它引入了“内容寻址存储”和“硬链接”的概念。我打个比方传统的包管理器像每人发一本实体书100个人就有100本。而 pnpm 像是在图书馆里只存一本母本然后给每个人发一张精确指向书中某个章节的“魔法书签”。当你需要读这本书时通过书签就能看到内容但物理上始终只有那一本书。这就是为什么 pnpm 能实现惊人的磁盘空间节省尤其是在 Monorepo 中几十个包共享相同的 React、Vue 等大型依赖时优势立现。它的另一个杀手锏是Workspace工作空间的原生支持。在项目根目录创建一个pnpm-workspace.yaml文件就能轻松定义哪些目录是子包packages: - apps/* # 所有的前端/后端应用 - packages/* # 共享的包如组件库、工具函数 - internal/* # 内部工具、配置定义好后你就可以使用pnpm add package --filter 子包名这样的命令精准地为某个子包安装依赖。更重要的是在子包的package.json里你可以用workspace:*来引用本地其他包这比file:../引用更可靠pnpm 会智能地处理这种链接关系。// apps/admin/package.json { dependencies: { my-company/ui-button: workspace:*, // 总是使用本地 workspace 的最新版本 lodash: ^4.17.21 } }2.2 Turborepo智能的构建系统加速器如果说 pnpm 解决了“静态”的依赖问题那么Turborepo解决的就是“动态”的构建和执行效率问题。在传统的 Monorepo 里你改了一个工具函数然后运行npm run build它很可能会傻乎乎地把所有包都重新构建一遍不管它们是否真的受到了影响。Turborepo 的核心是智能缓存和任务管道。它会分析你的代码和任务之间的依赖关系图。比如你定义了packages/utils的build任务依赖于它的源代码而apps/web的build任务又依赖于packages/utils。那么当你只修改了apps/web的源码时Turborepo 会跳过packages/utils的构建直接使用缓存中上次构建好的结果大大缩短时间。它的配置非常直观在根目录的turbo.json里定义任务管道{ $schema: https://turbo.build/schema.json, pipeline: { build: { dependsOn: [^build], // ^ 表示依赖所有上游包即依赖项的 build 任务 outputs: [.dist/**, build/**] // 告诉 turbo 哪些是构建产物需要缓存 }, test: { dependsOn: [build], // 本包的 test 依赖于本包的 build inputs: [src/**/*.ts, test/**/*.ts], // 只有这些文件变化才会使缓存失效 outputs: [] }, lint: { outputs: [] // 纯检查任务没有产物但结果成功/失败也会被缓存 }, dev: { cache: false // 开发服务器任务不缓存 } } }更厉害的是它的远程缓存。你可以在团队内部搭建一个共享的 Turborepo 缓存服务器。当同事 A 构建了某个包之后他的构建产物会被上传到远程缓存。同事 B 在拉取代码后构建同一个包时Turborepo 会直接下载缓存实现“一次构建多人受益”这在 CI/CD 流水线上效果拔群能节省大量的构建时间和计算资源。3. 搭建企业级 Monorepo 工程体系了解了“为什么”和“用什么”接下来我们动手从零开始搭建一个能满足企业级需求的前端 Monorepo。我会带你走过每一步并分享我踩过坑后总结的最佳实践。3.1 项目结构与初始化一个清晰、可扩展的项目结构是成功的一半。我推荐以下这种按功能分层的结构它在我经历过的多个中大型项目中都被验证是有效的my-enterprise-monorepo/ ├── apps/ # 应用层 │ ├── web-consumer/ # 面向消费者的主站 │ ├── web-admin/ # 后台管理系统 │ └── mobile-h5/ # 移动端 H5 项目 ├── packages/ # 共享包层 │ ├── ui/ # 基础 UI 组件库 │ │ ├── button/ │ │ ├── input/ │ │ └── index.ts │ ├── utils/ # 纯工具函数 │ ├── hooks/ # 自定义 React Hooks │ ├── config/ # 共享配置ESLint, Tailwind, 运行时配置 │ └── types/ # 全局 TypeScript 类型定义 ├── internal/ # 内部工具层可选 │ ├── cli/ # 自研脚手架 │ └── scripts/ # 构建、部署脚本 ├── package.json ├── pnpm-workspace.yaml # pnpm 工作空间定义 ├── turbo.json # Turborepo 任务管道配置 └── README.md初始化步骤很简单mkdir my-enterprise-monorepo cd my-enterprise-monorepo pnpm init然后创建pnpm-workspace.yaml文件内容就是我们上面提到的结构定义。3.2 配置 Turborepo 与任务管道安装 Turborepo 并创建配置文件pnpm add -Dw turbo接下来是重头戏设计turbo.json。企业级场景下我们需要考虑更复杂的任务依赖和缓存策略。下面是一个增强版的配置示例{ $schema: https://turbo.build/schema.json, globalDependencies: [.env.local, tsconfig.base.json], // 全局依赖文件它们变化会使所有缓存失效 pipeline: { build: { dependsOn: [^build, type-check], outputs: [dist/**, .next/**, .output/**, build/**], env: [NODE_ENV] // 环境变量也作为缓存键的一部分 }, type-check: { outputs: [] // 类型检查只有成功/失败状态缓存它可避免重复检查 }, lint: { outputs: [], inputs: [src/**/*.{ts,tsx,js,jsx}, eslint.config.js] // 明确输入更精准的缓存 }, test: { dependsOn: [build], inputs: [src/**/*.{ts,tsx}, test/**/*.{ts,tsx}, jest.config.js], outputs: [coverage/**] }, dev: { cache: false, persistent: true }, deploy: { dependsOn: [build, test, lint], cache: false } } }这个配置定义了一个严谨的流水线deploy部署前必须成功执行build、test和lint而build又依赖于所有它引用的包的build任务以及自身的type-check。这样确保了代码在构建前是类型安全且符合规范的。3.3 创建共享包与依赖管理现在我们来创建第一个共享包类型定义包。这能确保整个仓库使用一致的数据结构定义。mkdir -p packages/types cd packages/types pnpm init修改packages/types/package.json{ name: my-company/types, version: 1.0.0, types: ./dist/index.d.ts, main: ./dist/index.js, files: [dist], scripts: { build: tsup index.ts --format cjs,esm --dts, clean: rm -rf dist }, devDependencies: { tsup: ^8.0.0 } }在index.ts中定义全局类型// packages/types/index.ts export type ApiResponseT any { code: number; data: T; message: string; }; export type PaginationParams { page: number; pageSize: number; }; // 业务相关类型 export type UserProfile { id: string; name: string; avatar: string; email: string; };然后在其他包或应用中你就可以直接引用my-company/types了。通过pnpm add my-company/types --filter app-name来安装或者直接在目标package.json中用workspace:*引用。依赖管理技巧统一提升对于 React、Vue 等核心库建议在根目录的package.json中声明为devDependencies并使用pnpm的hoist配置将它们提升到根node_modules避免多个版本冲突。过滤安装使用--filter参数进行精准操作。例如只为所有应用安装一个测试库pnpm add -r vitest --filter ./apps/*。工作空间协议始终使用workspace:*或workspace:^来引用本地包这能保证在发布时pnpm 会自动将其转换为正确的版本范围。4. 进阶实践应对企业级复杂场景基础架子搭好了但企业级项目面临的挑战远不止于此。微前端、多环境配置、代码质量管控等都是必须跨过的坎。4.1 微前端架构下的 Monorepo 整合微前端和 Monorepo 是天作之合。Monorepo 提供了完美的“物理”隔离和“逻辑”统一的管理方式。我们可以将每个微前端应用或模块放在apps/目录下共享的组件、状态管理库放在packages/下。以基于 Module Federation 的 Webpack 5 微前端为例我们可以在 Monorepo 中这样组织apps/ ├── shell/ # 主应用容器 ├── app-dashboard/ # 仪表盘微应用 ├── app-settings/ # 设置微应用 packages/ ├── shared-react/ # 共享的 React 运行时避免重复打包 └── shared-state/ # 跨应用状态管理在每个微应用的package.json中通过workspace:*引用共享包。在构建配置中利用 Turborepo 的缓存可以并行构建所有微应用并且只有当某个应用或其依赖发生变化时才重新构建它极大地提升了 CI/CD 效率。4.2 统一的质量保障与开发规范在单体仓库中统一代码风格和质量标准变得既重要又容易。我们可以在packages/config下创建一系列共享配置。共享 ESLint 配置mkdir -p packages/config-eslint cd packages/config-eslint pnpm init// packages/config-eslint/index.js module.exports { extends: [eslint:recommended, plugin:typescript-eslint/recommended], parser: typescript-eslint/parser, plugins: [typescript-eslint], rules: { // 公司统一的代码规则 typescript-eslint/no-unused-vars: error, no-console: warn } };在各个子项目中只需继承这个配置eslintConfig: { extends: my-company/config-eslint }。共享 Prettier 与 Husky在根目录配置一套prettier规则并在根目录的package.json中安装和配置husky、lint-staged确保所有提交的代码都经过格式化与检查。// 根目录 package.json { scripts: { prepare: husky install, lint-staged: lint-staged }, lint-staged: { *.{js,ts,tsx,jsx}: [eslint --fix, prettier --write] } }这样无论在哪个子包中提交代码都会触发统一的钩子。4.3 环境变量、构建配置与发布管理环境变量管理创建一个packages/config-env包根据NODE_ENV等变量导出不同环境的配置API 地址、功能开关等。所有应用都依赖这个包来获取配置避免配置散落和硬编码。差异化构建不同应用可能需要不同的构建配置。我们可以在每个apps/xxx下维护自己的vite.config.ts或webpack.config.js但同时通过扩展一个位于packages/config-build中的基础配置来复用公共部分。版本管理与发布这是 Monorepo 的一个难点。我强烈推荐使用Changesets这个工具。它允许开发者声明哪些包需要更新以及是 patch、minor 还是 major 更新并自动生成更新日志CHANGELOG。pnpm add -Dw changesets/cli pnpm changeset init开发完成后运行pnpm changeset交互式地选择要发布的包和版本类型。Changesets 会生成一个变更集文件。在 CI 中可以自动根据这些文件计算版本号、更新package.json、生成 CHANGELOG 并发布到 npm。5. CI/CD 与远程缓存让团队飞起来个人开发效率的提升固然可喜但企业级工程化的价值更体现在团队协作和持续交付的提效上。Turborepo 的远程缓存功能在这里就是“神器”。5.1 搭建远程缓存你可以使用 Vercel 提供的免费远程缓存服务如果你在用他们的产品或者自己搭建一个。Turborepo 缓存服务器是一个简单的 Docker 容器# 使用官方镜像 docker run -p 8080:8080 -d vercel/turborepo-remote-cache然后在团队共享的 CI/CD 环境变量或开发者本地的.env.local中配置TURBO_APIhttp://your-cache-server:8080 TURBO_TOKENyour-secret-token TURBO_TEAMyour-team-name5.2 集成到 GitHub Actions下面是一个优化的 GitHub Actions CI 配置示例它充分利用了 pnpm 的缓存和 Turborepo 的远程缓存name: CI on: [push, pull_request] env: TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }} TURBO_API: ${{ secrets.TURBO_API }} jobs: build-and-test: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 with: fetch-depth: 2 # 为了 Turbo 能正确计算变更 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 cache: pnpm - name: Install pnpm run: npm install -g pnpm - name: Get pnpm store directory id: pnpm-cache run: | echo pnpm_cache_dir$(pnpm store path) $GITHUB_OUTPUT - name: Setup pnpm cache uses: actions/cachev4 with: path: ${{ steps.pnpm-cache.outputs.pnpm_cache_dir }} key: ${{ runner.os }}-pnpm-store-${{ hashFiles(**/pnpm-lock.yaml) }} restore-keys: | ${{ runner.os }}-pnpm-store- - name: Install dependencies run: pnpm install --frozen-lockfile - name: Type Check Lint run: pnpm turbo run type-check lint --parallel - name: Run Tests run: pnpm turbo run test - name: Build run: pnpm turbo run build --force # --force 确保即使有缓存也执行但会上传新缓存这个流水线实现了依赖缓存利用 GitHub Actions 缓存 pnpm 的全局 store安装依赖的速度极快。智能任务执行turbo run只会执行受代码变更影响的任务。远程缓存共享构建产物被上传到团队远程缓存其他成员或后续的 CI 运行可以直接命中缓存实现“一次构建处处可用”。5.3 处理 Monorepo 下的差异化部署对于部署我们可以利用turbo.json的filter参数。例如只部署发生变更的应用# 找出自上次发布以来有哪些应用发生了变更 CHANGED_APPS$(pnpm turbo run build --filter...[origin/main] --dry-runjson | jq -r .packages[] | grep ^apps/ | sed s/$/\// | paste -sd, -) if [ -n $CHANGED_APPS ]; then # 只构建和部署发生变更的应用 pnpm turbo run build deploy --filter$CHANGED_APPS fi这套组合拳打下来你会发现团队的开发流程变得异常顺畅。新成员入职一个git clone加pnpm install就能获得完整的、可立即开发的环境。功能开发涉及多个包在同一个仓库里修改、提交所有依赖关系自动同步。CI 上的构建时间从原来的几十分钟缩短到几分钟。这才是工程化带来的真实生产力解放。
Monorepo 进阶：用 pnpm + Turborepo 构建企业级前端工程体系
发布时间：2026/7/13 1:58:22
1. 从多仓库的泥潭中解放为什么企业级前端需要 Monorepo不知道你有没有经历过这样的场景公司里同时维护着五六个前端项目每个项目都长得差不多用的技术栈也类似但就是各自为政。你发现了一个公共组件的 bug需要改一个utils包结果你不得不跑到 A 项目的仓库里改一次提交、发版然后再跑到 B 项目的仓库里手动更新依赖版本再测试一遍。这还没完C 项目用的还是老版本你得去说服那个项目的负责人升级。光是沟通协调的时间就比写代码的时间还长。这就是传统MultiRepo多仓库模式下的日常团队规模越大业务线越多这种痛苦就越是成倍增长。MultiRepo 就像一个个独立的“小王国”初期确实简单清晰。但随着业务膨胀问题接踵而至代码复用变成了复制粘贴导致同一段逻辑散落在各处修个 bug 要打无数个补丁依赖版本四处飘散项目 A 用 React 18项目 B 还用着 16中间隔着一个大版本想统一升级那是一场牵一发而动全身的噩梦开发体验支离破碎每个项目都要配一遍 ESLint、Prettier、Jest构建配置也各有各的“祖传”写法新人上手得先熟悉好几个不同的“配方”。而Monorepo单一仓库提供的是一种“大一统”的解决方案。它把所有的项目、共享的包、工具配置都放在同一个代码仓库里管理。想象一下这就像一个大型超市所有商品代码模块分门别类地放在不同的货架上但它们共享同一个库存系统版本控制、同一套收银流程构建工具。你需要一个共享的按钮组件直接从packages/ui货架上拿所有用到它的应用立刻就能拿到最新版。这种模式带来的核心优势正是企业级开发所渴求的一致性、可维护性和开发效率的质变。不过光有 Monorepo 的概念还不够就像给你一块地告诉你这里能盖摩天大楼但没给你图纸和起重机。我们需要一套强大的工具链把蓝图变成现实。这就是pnpm和Turborepo这对“黄金搭档”登场的时候了。pnpm 负责解决依赖管理的混乱与磁盘空间危机而 Turborepo 则负责让整个仓库的构建和任务执行快如闪电。它们俩的结合才是构建一个健壮、高效的企业级前端工程体系的基石。2. 基石之选为什么是 pnpm Turborepo市面上包管理器和构建工具那么多为什么偏偏是它俩这可不是随便选的而是它们在 Monorepo 这个特定场景下用实实在在的优势拼出来的。2.1 pnpm为 Monorepo 而生的包管理器你可以把 npm 或 yarn 想象成传统的复制粘贴。安装lodash时它们会在每个项目的node_modules里都复制一份lodash的代码。如果有 10 个项目你的硬盘上就有 10 份一模一样的lodash。而pnpm的做法聪明得多它引入了“内容寻址存储”和“硬链接”的概念。我打个比方传统的包管理器像每人发一本实体书100个人就有100本。而 pnpm 像是在图书馆里只存一本母本然后给每个人发一张精确指向书中某个章节的“魔法书签”。当你需要读这本书时通过书签就能看到内容但物理上始终只有那一本书。这就是为什么 pnpm 能实现惊人的磁盘空间节省尤其是在 Monorepo 中几十个包共享相同的 React、Vue 等大型依赖时优势立现。它的另一个杀手锏是Workspace工作空间的原生支持。在项目根目录创建一个pnpm-workspace.yaml文件就能轻松定义哪些目录是子包packages: - apps/* # 所有的前端/后端应用 - packages/* # 共享的包如组件库、工具函数 - internal/* # 内部工具、配置定义好后你就可以使用pnpm add package --filter 子包名这样的命令精准地为某个子包安装依赖。更重要的是在子包的package.json里你可以用workspace:*来引用本地其他包这比file:../引用更可靠pnpm 会智能地处理这种链接关系。// apps/admin/package.json { dependencies: { my-company/ui-button: workspace:*, // 总是使用本地 workspace 的最新版本 lodash: ^4.17.21 } }2.2 Turborepo智能的构建系统加速器如果说 pnpm 解决了“静态”的依赖问题那么Turborepo解决的就是“动态”的构建和执行效率问题。在传统的 Monorepo 里你改了一个工具函数然后运行npm run build它很可能会傻乎乎地把所有包都重新构建一遍不管它们是否真的受到了影响。Turborepo 的核心是智能缓存和任务管道。它会分析你的代码和任务之间的依赖关系图。比如你定义了packages/utils的build任务依赖于它的源代码而apps/web的build任务又依赖于packages/utils。那么当你只修改了apps/web的源码时Turborepo 会跳过packages/utils的构建直接使用缓存中上次构建好的结果大大缩短时间。它的配置非常直观在根目录的turbo.json里定义任务管道{ $schema: https://turbo.build/schema.json, pipeline: { build: { dependsOn: [^build], // ^ 表示依赖所有上游包即依赖项的 build 任务 outputs: [.dist/**, build/**] // 告诉 turbo 哪些是构建产物需要缓存 }, test: { dependsOn: [build], // 本包的 test 依赖于本包的 build inputs: [src/**/*.ts, test/**/*.ts], // 只有这些文件变化才会使缓存失效 outputs: [] }, lint: { outputs: [] // 纯检查任务没有产物但结果成功/失败也会被缓存 }, dev: { cache: false // 开发服务器任务不缓存 } } }更厉害的是它的远程缓存。你可以在团队内部搭建一个共享的 Turborepo 缓存服务器。当同事 A 构建了某个包之后他的构建产物会被上传到远程缓存。同事 B 在拉取代码后构建同一个包时Turborepo 会直接下载缓存实现“一次构建多人受益”这在 CI/CD 流水线上效果拔群能节省大量的构建时间和计算资源。3. 搭建企业级 Monorepo 工程体系了解了“为什么”和“用什么”接下来我们动手从零开始搭建一个能满足企业级需求的前端 Monorepo。我会带你走过每一步并分享我踩过坑后总结的最佳实践。3.1 项目结构与初始化一个清晰、可扩展的项目结构是成功的一半。我推荐以下这种按功能分层的结构它在我经历过的多个中大型项目中都被验证是有效的my-enterprise-monorepo/ ├── apps/ # 应用层 │ ├── web-consumer/ # 面向消费者的主站 │ ├── web-admin/ # 后台管理系统 │ └── mobile-h5/ # 移动端 H5 项目 ├── packages/ # 共享包层 │ ├── ui/ # 基础 UI 组件库 │ │ ├── button/ │ │ ├── input/ │ │ └── index.ts │ ├── utils/ # 纯工具函数 │ ├── hooks/ # 自定义 React Hooks │ ├── config/ # 共享配置ESLint, Tailwind, 运行时配置 │ └── types/ # 全局 TypeScript 类型定义 ├── internal/ # 内部工具层可选 │ ├── cli/ # 自研脚手架 │ └── scripts/ # 构建、部署脚本 ├── package.json ├── pnpm-workspace.yaml # pnpm 工作空间定义 ├── turbo.json # Turborepo 任务管道配置 └── README.md初始化步骤很简单mkdir my-enterprise-monorepo cd my-enterprise-monorepo pnpm init然后创建pnpm-workspace.yaml文件内容就是我们上面提到的结构定义。3.2 配置 Turborepo 与任务管道安装 Turborepo 并创建配置文件pnpm add -Dw turbo接下来是重头戏设计turbo.json。企业级场景下我们需要考虑更复杂的任务依赖和缓存策略。下面是一个增强版的配置示例{ $schema: https://turbo.build/schema.json, globalDependencies: [.env.local, tsconfig.base.json], // 全局依赖文件它们变化会使所有缓存失效 pipeline: { build: { dependsOn: [^build, type-check], outputs: [dist/**, .next/**, .output/**, build/**], env: [NODE_ENV] // 环境变量也作为缓存键的一部分 }, type-check: { outputs: [] // 类型检查只有成功/失败状态缓存它可避免重复检查 }, lint: { outputs: [], inputs: [src/**/*.{ts,tsx,js,jsx}, eslint.config.js] // 明确输入更精准的缓存 }, test: { dependsOn: [build], inputs: [src/**/*.{ts,tsx}, test/**/*.{ts,tsx}, jest.config.js], outputs: [coverage/**] }, dev: { cache: false, persistent: true }, deploy: { dependsOn: [build, test, lint], cache: false } } }这个配置定义了一个严谨的流水线deploy部署前必须成功执行build、test和lint而build又依赖于所有它引用的包的build任务以及自身的type-check。这样确保了代码在构建前是类型安全且符合规范的。3.3 创建共享包与依赖管理现在我们来创建第一个共享包类型定义包。这能确保整个仓库使用一致的数据结构定义。mkdir -p packages/types cd packages/types pnpm init修改packages/types/package.json{ name: my-company/types, version: 1.0.0, types: ./dist/index.d.ts, main: ./dist/index.js, files: [dist], scripts: { build: tsup index.ts --format cjs,esm --dts, clean: rm -rf dist }, devDependencies: { tsup: ^8.0.0 } }在index.ts中定义全局类型// packages/types/index.ts export type ApiResponseT any { code: number; data: T; message: string; }; export type PaginationParams { page: number; pageSize: number; }; // 业务相关类型 export type UserProfile { id: string; name: string; avatar: string; email: string; };然后在其他包或应用中你就可以直接引用my-company/types了。通过pnpm add my-company/types --filter app-name来安装或者直接在目标package.json中用workspace:*引用。依赖管理技巧统一提升对于 React、Vue 等核心库建议在根目录的package.json中声明为devDependencies并使用pnpm的hoist配置将它们提升到根node_modules避免多个版本冲突。过滤安装使用--filter参数进行精准操作。例如只为所有应用安装一个测试库pnpm add -r vitest --filter ./apps/*。工作空间协议始终使用workspace:*或workspace:^来引用本地包这能保证在发布时pnpm 会自动将其转换为正确的版本范围。4. 进阶实践应对企业级复杂场景基础架子搭好了但企业级项目面临的挑战远不止于此。微前端、多环境配置、代码质量管控等都是必须跨过的坎。4.1 微前端架构下的 Monorepo 整合微前端和 Monorepo 是天作之合。Monorepo 提供了完美的“物理”隔离和“逻辑”统一的管理方式。我们可以将每个微前端应用或模块放在apps/目录下共享的组件、状态管理库放在packages/下。以基于 Module Federation 的 Webpack 5 微前端为例我们可以在 Monorepo 中这样组织apps/ ├── shell/ # 主应用容器 ├── app-dashboard/ # 仪表盘微应用 ├── app-settings/ # 设置微应用 packages/ ├── shared-react/ # 共享的 React 运行时避免重复打包 └── shared-state/ # 跨应用状态管理在每个微应用的package.json中通过workspace:*引用共享包。在构建配置中利用 Turborepo 的缓存可以并行构建所有微应用并且只有当某个应用或其依赖发生变化时才重新构建它极大地提升了 CI/CD 效率。4.2 统一的质量保障与开发规范在单体仓库中统一代码风格和质量标准变得既重要又容易。我们可以在packages/config下创建一系列共享配置。共享 ESLint 配置mkdir -p packages/config-eslint cd packages/config-eslint pnpm init// packages/config-eslint/index.js module.exports { extends: [eslint:recommended, plugin:typescript-eslint/recommended], parser: typescript-eslint/parser, plugins: [typescript-eslint], rules: { // 公司统一的代码规则 typescript-eslint/no-unused-vars: error, no-console: warn } };在各个子项目中只需继承这个配置eslintConfig: { extends: my-company/config-eslint }。共享 Prettier 与 Husky在根目录配置一套prettier规则并在根目录的package.json中安装和配置husky、lint-staged确保所有提交的代码都经过格式化与检查。// 根目录 package.json { scripts: { prepare: husky install, lint-staged: lint-staged }, lint-staged: { *.{js,ts,tsx,jsx}: [eslint --fix, prettier --write] } }这样无论在哪个子包中提交代码都会触发统一的钩子。4.3 环境变量、构建配置与发布管理环境变量管理创建一个packages/config-env包根据NODE_ENV等变量导出不同环境的配置API 地址、功能开关等。所有应用都依赖这个包来获取配置避免配置散落和硬编码。差异化构建不同应用可能需要不同的构建配置。我们可以在每个apps/xxx下维护自己的vite.config.ts或webpack.config.js但同时通过扩展一个位于packages/config-build中的基础配置来复用公共部分。版本管理与发布这是 Monorepo 的一个难点。我强烈推荐使用Changesets这个工具。它允许开发者声明哪些包需要更新以及是 patch、minor 还是 major 更新并自动生成更新日志CHANGELOG。pnpm add -Dw changesets/cli pnpm changeset init开发完成后运行pnpm changeset交互式地选择要发布的包和版本类型。Changesets 会生成一个变更集文件。在 CI 中可以自动根据这些文件计算版本号、更新package.json、生成 CHANGELOG 并发布到 npm。5. CI/CD 与远程缓存让团队飞起来个人开发效率的提升固然可喜但企业级工程化的价值更体现在团队协作和持续交付的提效上。Turborepo 的远程缓存功能在这里就是“神器”。5.1 搭建远程缓存你可以使用 Vercel 提供的免费远程缓存服务如果你在用他们的产品或者自己搭建一个。Turborepo 缓存服务器是一个简单的 Docker 容器# 使用官方镜像 docker run -p 8080:8080 -d vercel/turborepo-remote-cache然后在团队共享的 CI/CD 环境变量或开发者本地的.env.local中配置TURBO_APIhttp://your-cache-server:8080 TURBO_TOKENyour-secret-token TURBO_TEAMyour-team-name5.2 集成到 GitHub Actions下面是一个优化的 GitHub Actions CI 配置示例它充分利用了 pnpm 的缓存和 Turborepo 的远程缓存name: CI on: [push, pull_request] env: TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }} TURBO_API: ${{ secrets.TURBO_API }} jobs: build-and-test: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkoutv4 with: fetch-depth: 2 # 为了 Turbo 能正确计算变更 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 cache: pnpm - name: Install pnpm run: npm install -g pnpm - name: Get pnpm store directory id: pnpm-cache run: | echo pnpm_cache_dir$(pnpm store path) $GITHUB_OUTPUT - name: Setup pnpm cache uses: actions/cachev4 with: path: ${{ steps.pnpm-cache.outputs.pnpm_cache_dir }} key: ${{ runner.os }}-pnpm-store-${{ hashFiles(**/pnpm-lock.yaml) }} restore-keys: | ${{ runner.os }}-pnpm-store- - name: Install dependencies run: pnpm install --frozen-lockfile - name: Type Check Lint run: pnpm turbo run type-check lint --parallel - name: Run Tests run: pnpm turbo run test - name: Build run: pnpm turbo run build --force # --force 确保即使有缓存也执行但会上传新缓存这个流水线实现了依赖缓存利用 GitHub Actions 缓存 pnpm 的全局 store安装依赖的速度极快。智能任务执行turbo run只会执行受代码变更影响的任务。远程缓存共享构建产物被上传到团队远程缓存其他成员或后续的 CI 运行可以直接命中缓存实现“一次构建处处可用”。5.3 处理 Monorepo 下的差异化部署对于部署我们可以利用turbo.json的filter参数。例如只部署发生变更的应用# 找出自上次发布以来有哪些应用发生了变更 CHANGED_APPS$(pnpm turbo run build --filter...[origin/main] --dry-runjson | jq -r .packages[] | grep ^apps/ | sed s/$/\// | paste -sd, -) if [ -n $CHANGED_APPS ]; then # 只构建和部署发生变更的应用 pnpm turbo run build deploy --filter$CHANGED_APPS fi这套组合拳打下来你会发现团队的开发流程变得异常顺畅。新成员入职一个git clone加pnpm install就能获得完整的、可立即开发的环境。功能开发涉及多个包在同一个仓库里修改、提交所有依赖关系自动同步。CI 上的构建时间从原来的几十分钟缩短到几分钟。这才是工程化带来的真实生产力解放。
 文本标签、图片标签)
