Monorepo 是什么？pnpm workspace 如何管理多个项目和公共依赖？

知识点详解：共享代码以后，怎样知道谁受影响？

先搭一个最小工作区

假设咱们维护网站 web、管理后台 admin，以及它们共享的组件包 ui。

repo/
  apps/web/
  apps/admin/
  packages/ui/
  pnpm-workspace.yaml

根目录的工作区配置可以写成：

packages:
  - 'apps/*'
  - 'packages/*'

每个项目仍然有自己的 package.json。目录只是发现包的入口，真实包名、脚本和依赖，来自包自身的声明。

这个例子展示 pnpm 的配置，不是 Python 包管理接口。仓库也可以包含 Python 服务，但它仍需要自己的 Python 依赖与构建配置，不能把 pnpm 安装当成通用语言管理器。

workspace 协议，为什么比“本地有这个包”明确？

假设共享包名为 @demo/ui。应用可以声明：

{
  "dependencies": {
    "@demo/ui": "workspace:*"
  }
}

workspace 协议要求使用对应工作区包。普通版本范围是否链接本地，还受版本和配置影响；没有满足条件的本地包时，可能走注册表解析。

因此，公共包明明在仓库里，不代表任何同名依赖都会自动使用它。发布或打包时，workspace 依赖还需要转换成对外可使用的版本约定，具体行为见 pnpm 工作区文档。

使用了源码，还是使用构建产物？

工作区关联只让包能够按依赖关系被找到。最终加载什么，仍由包的入口、exports、类型声明和业务构建配置决定。

如果 ui 暴露的是 dist 里的文件，应用运行前就需要确保 ui 已经正确构建。链接到本地目录，并不会自动生成 dist。

开发时直接消费源码也是一种选择，但要确认转译、样式和依赖都由谁处理。不要开发环境读源码、发布环境读旧产物，却没有验证二者的一致性。

三张关系，为什么不能混在一起？

第一张是包依赖：web 和 admin 都依赖 ui。

第二张是任务依赖：构建 web 可能需要先生成 ui 产物，测试任务则可能有不同前置条件。

第三张是发布关系：ui 可以单独版本发布，两个应用也可以独立部署，或者团队选择统一版本。Monorepo 不强制它们永远一起发布。

改动影响分析需要结合这些关系与真实输入。根配置、构建工具、锁文件变化，可能影响很多项目；只按“哪个目录的文件变了”决定测试范围，会漏掉问题。

公共包为什么容易越来越大？

任何共享代码都塞进 ui 或 utils，短期省事，长期会让两个原本独立的应用互相牵制。

应该让包有清楚职责和公开入口。应用专属规则不要因为“以后可能复用”，就立刻放进公共层。跨包修改也应有测试与负责人，不等于谁都能随意改所有项目。

循环依赖尤其要检查。A 依赖 B、B 又依赖 A，会破坏清晰构建顺序，某些脚本无法保证拓扑执行。需要调整边界，而不是简单隐藏工具警告。

怎样验证工作区真的可发布？

从干净环境安装依赖，按任务顺序构建，再验证应用只通过声明的公开入口消费共享包。

如果共享包要对外分发，还要测试真实打包产物。仓库里能引用到某个文件，不代表包发布以后那个文件仍然存在。

缓存则要包含源码、依赖与构建配置等真实输入。缓存命中但输出属于旧配置，比构建慢一点更难排查。

面试官继续追问

Monorepo 必须统一技术栈吗？

不必须。同仓可以有不同语言和工具，但依赖、CI 与部署关系需要明确，不能指望一种包管理器代替所有工具。

所有依赖都提升到根目录，最方便吗？

根工具与包运行依赖需要区分。包应该声明自己真实使用的依赖，避免在仓库里碰巧能用，单独打包就失败。

它一定比多仓库好吗？

跨项目协作频繁时可能更方便；独立权限、生命周期和发布节奏很重要时，多仓也有合理性。拿具体维护压力比较，不按“规模大就要 Monorepo”判断。

面试速记卡

• Monorepo 管同仓多项目，不强制统一语言与发布。
• workspace 发现包，每个包仍声明自己的依赖。
• workspace 协议明确要求使用工作区包。
• 本地链接不等于构建产物已经生成。
• 包依赖、任务依赖、发布关系分别梳理。
• 干净构建与真实打包测试，验证仓库外也能使用。