跳到主内容
Version: 5.x

工作空间

pnpm 内置了对单一存储库(也称为多包存储库、 多项目存储库或单体存储库)的支持。 您可以创建一个工作区以将多个项目合并到一个存储库中。

工作空间的根目录中必须有 pnpm-workspace.yaml 文件。 工作空间的根目录中也可能有 .npmrc

工作空间协议 (workspace:)

Supported since v3.7.0.

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

Luckily, pnpm supports the workspace: protocol (the same as in Yarn v2). 当使用此协议时,pnpm 将拒绝解析除本地工作区 package 之外的任何内容。 因此,如果您设置为 "foo": "workspace:2.0.0" 时,安装将会失败,因为 "foo@2.0.0" 不存在于工作空间中。

link-workspace-packages 选项 设置为 false时,这个协议就尤其有用。 在这种情况下,仅当使用 workspace:协议声明依赖,pnpm 才会从工作空间链接所需的包。

通过别名引用工作空间包

Added in 5.12.0

假设您在工作区有一个名为 foo 的包。 通常你会像这样引用:"foo": "workspace:*"

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

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

通过相对路径引用工作区包

Added in 5.12.0

工作区内有两个软件包:

+ packages
+ foo
+ bar

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

发布工作空间包

当工作空间包打包到归档(无论它是通过 pnpm pack ,还是 pnpm publish 之类的发布命令)时,我们将动态替换这些 workspace: 依赖:

  • The corresponding version in the target workspace (if you use *)
  • 相关的 semver 范围(对于任何其他范围类型)

So for example, if we have a workspace package at version 1.5.0, the following:

{
"dependencies": {
"foo": "workspace:*",
"bar": "workspace:^1.2.3"
}
}

将转化为:

{
"dependencies": {
"foo": "1.5.0",
"bar": "^1.2.3"
}
}

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

发布工作空间 (release workspace)

工作空间内的 packages 的版本管理是个十分复杂的任务, pnpm暂未支持内置的解决方案。 不过,有两个测试完好的工具可以处理版本管理且支持 pnpm

有关如何用 Rush 建立仓库,请阅读这篇文章

有关在 pnpm 中使用Changesets ,请阅读这里

配置项

添加于:v2.14.0

  • 默认值: true
  • 类型: true, false, deep

如果启用了此选项,本地可用的packages将被链接到 node_modules 中而不是从注册表下载。 这在 monorepo 项目中使用起来将十分方便。 如果您需要将本地 packages 也链接到子依赖项,则可以设置为 deep (自 v5 版本起)。

否则, packages 将全部从注册表下载并安装。 不过,工作空间的 packages 仍然可以通过 workspace: 范围协议被链接到。

prefer-workspace-packages

添加于: v5.13.0

  • 默认值: false
  • 类型:Boolean

如果启用了此选项,工作空间中的本地 package 将优先于注册表,即使注册表中有了该 package 的新版本。

该设置只在工作空间未开启 save-workspace-protocol 时有效。

shared-workspace-lockfile

添加于:v2.17.0 为 shared-workspace-shrinkwrap减

  • 默认值: true
  • 类型:Boolean

如果启用此选项,pnpm 会在工作空间的根目录中创建一个唯一的 pnpm-lock.yaml 文件。 这也意味着工作空间的packages的所有依赖项都将位于单个 node_modules 中。(同时软链接到它们packagesnode_modules 文件夹中用于 Node 的模块解析)。

此选项的好处:

  • 每个依赖都是一个单例
  • 在 monorepo 中的安装更快
  • 代码更改都在一个文件中、代码审查(Cr )减少
note

尽管所有依赖项都将硬链接到根 node_modules 中,但packages 只能访问 package.json 中声明的 ,因此 pnpm 的严格性得以保留。 这是上述软链接的效果。

save-workspace-protocol

  • 默认值: true
  • 类型:Boolean

如果启用此选项,新的依赖将会被工作空间协议 workspace:添加,当且仅当依赖存在于工作空间时。

如果您项目中的工具不支持工作空间协议,您可能希望将此设置更改为 false(最好提交一个 PR 让其在后续可以支持)。