yarn workspace深度解析
## 关于 Yarn Workspace 的一些技术随想
最近在整理项目代码时，又用到了 Yarn Workspace 这个工具。说起来，它已经不算是什么新鲜玩意儿了，但在实际开发中，尤其是在处理那些逐渐膨胀、模块越来越多的前端或 Node.js 项目时，它的价值才会真正凸显出来。这里就聊聊对它的理解和使用上的一些心得，不是什么官方教程，更像是一些经验性的记录。
它究竟是什么
简单来说，Yarn Workspace 是 Yarn 包管理器提供的一个功能。它的核心目的，是让你能够在一个大的项目根目录下，管理多个相互关联的包（package）。你可以把它想象成一个“项目集合”的管理器。
在没有它的时候，如果我们有几个内部关联紧密的 npm 包，通常的做法可能是为每个包单独建立一个仓库，分别进行版本管理和发布。这当然可以，但开发调试起来会非常麻烦：你需要在 A 包开发，然后npm link到 B 包测试，或者频繁地发布测试版本，流程繁琐，反馈周期长。
Yarn Workspace 提供了一种“单体仓库”（Monorepo）的解决方案。它允许你把所有这些相关的包都放在同一个代码仓库里，但每个包又保持自己的独立性，有自己的package.json。Yarn 会智能地处理这些包之间的依赖关系，特别是当它们彼此引用时。
它能解决什么问题
它的能力可以归结为几个非常具体的痛点。
首先，简化了本地依赖的链接。假设你有一个@project/ui-components组件库和一个@project/admin应用。在 Workspace 下，你只需要在admin的package.json里声明依赖"@project/ui-components": "1.0.0"。Yarn 会自动将这个依赖指向仓库内的ui-components目录，而不是去远程 npm 仓库寻找。你修改了组件库的代码，应用这边立刻就能感知到，就像它们在同一项目中一样，省去了npm link的步骤和不稳定性。
其次，统一和提升依赖安装效率。所有子包的依赖（node_modules）会被尽可能地“提升”到项目根目录安装。这意味着，如果多个子包都依赖了相同版本的react，那么根目录下只会安装一份react，各个子包通过软链的方式去引用它。这大大减少了磁盘空间的占用，也加快了yarn install的速度。
再者，方便执行批量脚本。你可以在根目录使用yarn workspace <package-name> <command>来针对某个特定子包运行命令，也可以用yarn workspaces run <command>让所有子包都执行同一个命令（比如lint或test）。这对于统一代码风格、执行集体测试或构建非常方便。
最后，它为代码重构和跨包变更提供了便利。所有相关的代码都在一个仓库里，当你需要修改一个被多个包使用的公共 API 时，可以在一次提交中完成所有改动，更容易保证一致性，也便于代码审查。
基本的使用方法
用起来并不复杂。首先，确保你的 Yarn 版本在 1.0 以上（现在推荐用 Berry 版本，即 Yarn 2+）。
第一步，在项目的根目录创建一个package.json，并设置private: true（根目录本身通常不是一个可发布的包）。关键是要加上"workspaces"字段，它的值是一个数组，指明哪些目录是子包。
{"name":"my-monorepo","private":true,"workspaces":["packages/*"]}上面的配置意味着所有在packages/目录下的文件夹都会被当作一个独立的 Workspace 包。你也可以明确列出，比如["packages/ui", "packages/utils"]。
第二步，按照你设定的路径，比如packages/下，创建各个子包目录。每个子包都必须有自己的package.json，其中name字段是必须的。
一个典型的目录结构可能长这样：
my-monorepo/ ├── package.json (根，含 workspaces 配置) ├── node_modules/ (提升的依赖) ├── packages/ │ ├── button/ │ │ ├── package.json (name: "@project/button") │ │ └── src/ │ ├── modal/ │ │ ├── package.json (name: "@project/modal") │ │ └── src/ │ └── app/ │ ├── package.json (name: "@project/app"，依赖 @project/button 和 @project/modal) │ └── src/第三步，在根目录运行yarn install。Yarn 会分析所有子包的依赖，进行扁平化安装和链接。之后，你就可以使用yarn workspace @project/app add some-external-lib来为特定包添加外部依赖，或者在根目录运行yarn workspaces run build来构建所有包。
一些实践中的体会
用了一段时间后，会积累一些算不上“最佳”，但很实用的经验。
规划好包的结构和职责是最重要的一步。不要为了用 Workspace 而强行拆分包。一个包应该有明确、单一的职责。如果两个模块耦合度极高，且几乎没有独立复用的可能，那么放在同一个包里也许是更好的选择。过度拆分会导致依赖管理复杂，脚本执行缓慢。
注意依赖版本。虽然 Yarn 会提升公共依赖，但如果不同子包对同一个第三方库声明了不兼容的版本（比如lodash@^4和lodash@^3），可能会产生问题。尽量统一公共库的版本。对于内部包之间的依赖，在开发期可以使用"*"或"workspace:*"（Yarn 2+）来总是引用本地最新版本，方便联调；但在准备发布时，需要将其固定为具体的版本号。
利用好根目录的脚本。在根package.json的scripts里定义一些复合命令，能极大提升效率。比如定义一个"dev": "yarn workspace @project/app dev"，这样在根目录运行yarn dev就能启动主应用。或者定义一个复杂的构建序列"build:all": "yarn workspaces run build && yarn workspace @project/app bundle"。
工具链的统一。由于所有包在一个仓库，像 TypeScript、ESLint、Prettier、Jest 这些工具的配置，可以在根目录维护一份共享的配置，各子包按需扩展。这能有效保证代码质量的一致性。Yarn 2+ 的yarn dlx命令可以方便地在项目上下文中运行一次性工具，很适合这种环境。
考虑好发布流程。当需要发布内部包到 npm 仓库时，需要工具辅助。lerna是一个经典的选择，它擅长处理版本号和发布。实际上，在 Yarn Workspace 早期，很多人会配合 Lerna 使用。不过，Yarn 2+ 自身也提供了yarn npm publish和插件如@yarnpkg/plugin-workspace-tools来增强工作区管理，可以根据项目复杂度进行选择。
与同类思路的简单对比
提到代码仓库的组织，除了这种“单体仓库”（Monorepo）模式，自然就是传统的“多仓库”（Multirepo）模式了。前面已经说了，多仓库在独立发布、权限隔离上有优势，但开发调试体验差，协同变更困难。
在 Monorepo 的实现工具上，除了 Yarn Workspace，常见的还有前面提到的Lerna，以及Npm Workspaces、Pnpm Workspaces等。
Lerna出现得更早，它本身不直接管理node_modules，而是侧重于版本管理和发布（“Version and Publish”）。它需要配合 Yarn 或 Npm 来管理依赖。在 Yarn Workspace 成熟后，很多项目采用“Yarn Workspace + Lerna”的组合，用 Yarn 处理依赖安装和链接，用 Lerna 处理版本号提升和发布。这是一个非常强大且流行的方案。
Npm Workspaces是 Npm 7 开始内置的功能，理念和 Yarn Workspace 类似。如果你的团队主要使用 npm 且版本较新，它是个不错的原生选择。不过在一些高级功能和社区插件生态上，可能不如 Yarn 丰富。
Pnpm Workspaces与 Pnpm 这个包管理器绑定。Pnpm 以其高效的磁盘利用（硬链接）和严格的依赖结构著称。如果你选择 Pnpm 作为包管理器，它的 Workspace 功能同样出色，并且能发挥 Pnpm 在依赖安装速度和存储上的优势。
怎么选呢？一个比较实际的看法是：如果你已经深度使用 Yarn，并且项目结构不是极其复杂到需要 Lerna 那种精细的版本发布流程，那么 Yarn Workspace 本身可能就足够了。如果你需要复杂的多包版本管理和自动化发布，那么“Yarn Workspace + Lerna”依然是黄金组合。如果追求极致的安装效率和磁盘空间节省，可以认真评估一下 Pnpm。
说到底，工具都是为了解决特定场景下的问题。Yarn Workspace 提供了一种优雅的方式来管理内部紧密关联的多个包，让开发体验更接近一个单一项目，同时又保留了模块化的清晰边界。它不一定适合所有场景，但在它适合的场景里，用起来确实会顺手很多。