工作空间(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:)
If link-workspace-packages is set to true
, pnpm will link packages from the workspace if the available packages match the declared ranges. 例如, 如果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:~
, orworkspace:^
) - 相关的 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,可以阅读这篇指南。