跳到主内容
版本：8.x

工作空间（Workspace）

pnpm 内置了对单一存储库（也称为多包存储库、多项目存储库或单体存储库）的支持， 你可以创建一个 workspace 以将多个项目合并到一个仓库中。

一个 workspace 的根目录下必须有 pnpm-workspace.yaml 文件， 也可能会有 .npmrc 文件。

提示

如果您正在思考如何管理 monorepo 项目，您可能还想看一下 Bit。 Bit 在后台使用 pnpm，但将许多当前在由 pnpm/npm/Yarn 管理的传统工作区中手动完成的事情自动化。 有一篇关于 bit install 的文章谈到了它： Painless Monorepo Dependency Management with Bit。

Workspace 协议 (workspace:)​

默认情况下，如果可用的 packages 与已声明的可用范围相匹配，pnpm 将从工作区链接这些 packages。 例如, 如果bar引用"foo": "^1.0.0"并且foo@1.0.0存在工作区，那么pnpm会从工作区将foo@1.0.0链接到bar。 但是，如果 bar 的依赖项中有 "foo": "2.0.0"，而 foo@2.0.0 在工作空间中并不存在，则将从 npm registry 安装 foo@2.0.0 。 这种行为带来了一些不确定性。

幸运的是，pnpm 支持 workspace 协议 workspace: 。 当使用此协议时，pnpm 将拒绝解析除本地 workspace 包含的 package 之外的任何内容。 因此，如果您设置为 "foo": "workspace:2.0.0" 时，安装将会失败，因为 "foo@2.0.0" 不存在于此 workspace 中。

当 link-workspace-packages 选项被设置为 false 时，这个协议将特别有用。 在这种情况下，仅当使用 workspace: 协议声明依赖，pnpm 才会从此 workspace 链接所需的包。

通过别名引用 workspace 包​

假设你在 workspace 中有一个名为 foo 的包， 通常你会像这样引用："foo": "workspace:*"。

如果要使用其他别名，那么以下语法也将起作用: "bar": "workspace:foo@*"。

在发布之前，别名被转换为常规名称。 上面的示例将变为："bar": "npm:foo@1.0.0"。

通过相对路径引用 workspace 包​

假如 workspace 中有两个包：

+ packages
    + foo
    + bar

bar 中可能有 foo 的依赖： "foo": "workspace:../foo"， 在发布之前，这些将转换为所有包管理器支持的常规版本规范。

发布 workspace 包​

当 workspace 包打包到归档（无论它是通过 pnpm pack ，还是 pnpm publish 之类的发布命令）时，我们将动态替换这些 workspace: 依赖：

  • 目标 workspace 中的对应版本（如果使用 workspace:*, workspace:~, or workspace:^）
  • 相关的 semver 范围（对于任何其他范围类型）

看一个例子，假设我们的 workspace 中有 foo、 bar、 qar、 zoo 并且它们的版本都是 1.5.0，如下：

{
    "dependencies": {
        "foo": "workspace:*",
        "bar": "workspace:~",
        "qar": "workspace:^",
        "zoo": "workspace:^1.5.0"
    }
}

将会被转化为：

{
    "dependencies": {
        "foo": "1.5.0",
        "bar": "~1.5.0",
        "qar": "^1.5.0",
        "zoo": "^1.5.0"
    }
}

这个功能允许你发布转化之后的包到远端，并且可以正常使用本地 workspace 中的 packages，而不需要其它中间步骤。包的使用者也可以像常规的包那样正常使用，且仍然可以受益于语义化版本。

发布工作流​

workspace 中的包版本管理是一个复杂的任务，pnpm 目前也并未提供内置的解决方案。 不过，有两个不错且支持 pnpm 的版本控制工具可以使用：

有关如何用 Rush 设置仓库，可以阅读 这篇文章。

有关在 pnpm 中使用 Changesets，可以阅读这篇指南。

故障排查​

如果工作空间依赖项之间存在循环，则 pnpm 无法保证脚本将按拓扑顺序运行。 如果 pnpm 在安装过程中检测到循环依赖，则会提供一个 warning 警告。 如果 pnpm 能够找出导致循环的依赖项，也会将其展示出来。

如果您看到此消息 There are cyclic workspace dependencies ，请检查在dependencies, optionalDependencies 和 devDependencies 中声明的工作空间依赖。

使用示例​

以下是几个使用了 pnpm 工作空间功能的最受欢迎的开源项目：

项目获得星星的数量迁移日期迁移提交
Next.js2022-05-29f7b81316aea4fc9962e5e54981a6d559004231aa
Material UI2024-01-03a1263e3e5ef8d840252b4857f85b33caa99f471d
Vite2021-09-263e1cce01d01493d33e50966d0d0fd39a86d229f9
Nuxt2022-10-1774a90c566c936164018c086030c7de65b26a5cb6
Vue 3.02021-10-0961c5fbd3e35152f5f32e95bf04d3ee083414cecb
Astro2022-03-08240d88aefe66c7d73b9c713c5da42ae789c011ce
n8n2022-11-09736777385c54d5b20174c9c1fda38bb31fbf14b4
Prisma2021-09-21c4c83e788aa16d61bae7a6d00adc8a58b3789a06
Slidev2021-04-12d6783323eb1ab1fc612577eb63579c8f7bc99c3a
Turborepo2022-03-02fd171519ec02a69c9afafc1bc5d9d1b481fba721
Ember.js2023-10-18b6b05da662497183434136fb0148e1dec544db04
Element Plus2021-09-23f9e192535ff74d1443f1d9e0c5394fad10428629
NextAuth.js2022-05-034f29d39521451e859dbdb83179756b372e3dd7aa
Qwik2022-11-14021b12f58cca657e0a008119bc711405513e1ee9
VueUse2021-09-25826351ba1d9c514e34426c85f3d69fb9875c7dd9
SvelteKit2021-09-26b164420ab26fa04fd0fbe0ac05431f36a89ef193
Verdaccio2021-09-219dbf73e955fcb70b0a623c5ab89649b95146c744
Vercel2023-01-129c768b98b71cfc72e8638bf5172be88c39e8fa69
Vitest2021-12-13d6ff0ccb819716713f5eab5c046861f4d8e4f988
Cycle.js2021-09-21f2187ab6688368edb904b649bd371a658f6a8637
Milkdown2021-09-264b2e1dd6125bc2198fd1b851c4f00eda70e9b913
Nhost2022-02-0710a1799a1fef2f558f737de3bb6cadda2b50e58f
Logto2021-07-290b002e07850c8e6d09b35d22fab56d3e99d77043
Rollup plugins2021-09-2153fb18c0c2852598200c547a0b1d745d15b5b487
icestark2021-12-164862326a8de53d02f617e7b1986774fd7540fccd
ByteMD2021-02-1836ef25f1ea1cd0b08752df5f8c832302017bb7fb