工作區
pnpm 內建了對 Monorepo (單一存放庫，又稱為多重套件存放庫、多重專案存放庫或整合型存放庫) 的支援。 您可以建立一個工作區來將多個專案結合在單個存放庫的內部。
A workspace must have a pnpm-workspace.yaml file in its
root.
If you are looking into monorepo management, you might also want to look into Bit.
Bit 實際上使用的是 pnpm，不過它會自動執行許多動作，目前在 pnpm/npm/Yarn 管理的傳統工作區中，這些動作則需要手動執行。 There's an article about bit install that talks about it: Painless Monorepo Dependency Management with Bit.
工作區通訊協定 (workspace:)
If linkWorkspacePackages is set to true, pnpm will link packages from the workspace if the available packages
match the declared ranges. For instance, foo@1.0.0 is linked into bar if
bar has "foo": "^1.0.0" in its dependencies and foo@1.0.0 is in the workspace. However, if bar has
"foo": "2.0.0" in dependencies and foo@2.0.0 is not in the workspace,
foo@2.0.0 will be installed from the registry. 這個行為會導致一些不確定性。
Luckily, pnpm supports the workspace: protocol. 使用此通訊協定時，pnpm 會拒絕解析除本機工作區套件之外的任何內容。 So, if you set "foo": "workspace:2.0.0", this time
installation will fail because "foo@2.0.0" isn't present in the workspace.
This protocol is especially useful when the linkWorkspacePackages option is
set to false. In that case, pnpm will only link packages from the workspace if
the workspace: protocol is used.
透過別名參考工作區套件
Let's say you have a package in the workspace named foo. Usually, you would
reference it as "foo": "workspace:*".
If you want to use a different alias, the following syntax will work too:
"bar": "workspace:foo@*".
發佈前，別名會轉換為標準的別名相依性。 The above
example will become: "bar": "npm:foo@1.0.0".
透過相對路徑參考工作區套件
在具有 2 個套件的工作區中：
+ packages
+ foo
+ bar
bar may have foo in its dependencies declared as
"foo": "workspace:../foo". 發布前，這些規格會轉換為所有套件管理器都支援的標準版本規格。
發佈工作區套件
When a workspace package is packed into an archive (whether it's through
pnpm pack or one of the publish commands like pnpm publish), we dynamically
replace any workspace: dependency by:
- The corresponding version in the target workspace (if you use
workspace:*,workspace:~, orworkspace:^) - 相關聯的 SemVer 範圍 (適用於其他任何範圍類型)
So for example, if we have foo, bar, qar, zoo in the workspace and they all are at version 1.5.0, the following:
{
"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"
}
}
這個功能允許您在相依於本機工作區的套件時，仍然能夠將產生的套件發佈至遠端登錄檔，而無須中繼的發佈步驟。您的消費者將能夠將發佈的工作區像其他任何套件一樣使用，仍然得益於 SemVer 提供的保證。
釋出工作流程
對工作區內的套件進行版本設定是一項複雜的工作，pnpm 目前不為此提供內建解決方案。 不過，有 2 個經過充分測試的工具可以處理版本設定且支援 pnpm：
For how to set up a repository using Rush, read this page.
For using Changesets with pnpm, read this guide.
疑難排解
工作區相依性之間有循環時，pnpm 將無法保證程式碼以拓撲順序執行。 如果 pnpm 在安裝期間偵測到相依性循環，則將會產生一個警告。 如果 pnpm 能夠找出導致循環的相依性，則也會將其顯示。
If you see the message There are cyclic workspace dependencies, please inspect workspace dependencies declared in dependencies, optionalDependencies and devDependencies.
使用範例
以下是使用 pnpm 工作區功能的幾個最熱門的開源專案：
設定
linkWorkspacePackages
- 預設值：false
- Type: true, false, deep
If this is enabled, locally available packages are linked to node_modules
instead of being downloaded from the registry. This is very convenient in a
monorepo. If you need local packages to also be linked to subdependencies, you
can use the deep setting.
Else, packages are downloaded and installed from the registry. However,
workspace packages can still be linked by using the workspace: range protocol.
Packages are only linked if their versions satisfy the dependency ranges.
injectWorkspacePackages
- 預設值：false
- 型別：布林值
Enables hard-linking of all local workspace dependencies instead of symlinking them. Alternatively, this can be achieved using dependenciesMeta[].injected, which allows to selectively enable hard-linking for specific dependencies.
Even if this setting is enabled, pnpm will prefer to deduplicate injected dependencies using symlinks—unless multiple dependency graphs are required due to mismatched peer dependencies. This behaviour is controlled by the dedupeInjectedDeps setting.
dedupeInjectedDeps
- Default: true
- 型別：布林值
When this setting is enabled, dependencies that are injected will be symlinked from the workspace whenever possible. If the dependent project and the injected dependency reference the same peer dependencies, then it is not necessary to physically copy the injected dependency into the dependent's node_modules; a symlink is sufficient.
syncInjectedDepsAfterScripts
Added in: v10.5.0
- Default: undefined
- Type: String[]
Injected workspace dependencies are collections of hardlinks, which don't add or remove the files when their sources change. This causes problems in packages that need to be built (such as in TypeScript projects).
This setting is a list of script names. When any of these scripts are executed in a workspace package, the injected dependencies inside node_modules will also be synchronized.
preferWorkspacePackages
- 預設值：false
- 型別：布林值
If this is enabled, local packages from the workspace are preferred over packages from the registry, even if there is a newer version of the package in the registry.
This setting is only useful if the workspace doesn't use
saveWorkspaceProtocol.
sharedWorkspaceLockfile
- Default: true
- 型別：布林值
If this is enabled, pnpm creates a single pnpm-lock.yaml file in the root of
the workspace. This also means that all dependencies of workspace packages will
be in a single node_modules (and get symlinked to their package node_modules
folder for Node's module resolution).
Advantages of this option:
- every dependency is a singleton
- faster installations in a monorepo
- fewer changes in code reviews as they are all in one file
Even though all the dependencies will be hard linked into the root
node_modules, packages will have access only to those dependencies
that are declared in their package.json, so pnpm's strictness is preserved.
This is a result of the aforementioned symbolic linking.
saveWorkspaceProtocol
- Default: rolling
- Type: true, false, rolling
This setting controls how dependencies that are linked from the workspace are added to package.json.
If foo@1.0.0 is in the workspace and you run pnpm add foo in another project of the workspace, below is how foo will be added to the dependencies field. The savePrefix setting also influences how the spec is created.
| saveWorkspaceProtocol | savePrefix | spec |
|---|---|---|
| false | '' | 1.0.0 |
| false | '~' | ~1.0.0 |
| false | '^' | ^1.0.0 |
| true | '' | workspace:1.0.0 |
| true | '~' | workspace:~1.0.0 |
| true | '^' | workspace:^1.0.0 |
| rolling | '' | workspace:* |
| rolling | '~' | workspace:~ |
| rolling | '^' | workspace:^ |
includeWorkspaceRoot
- 預設值：false
- 型別：布林值
When executing commands recursively in a workspace, execute them on the root workspace project as well.
ignoreWorkspaceCycles
- 預設值：false
- 型別：布林值
When set to true, no workspace cycle warnings will be printed.
disallowWorkspaceCycles
- 預設值：false
- 型別：布林值
When set to true, installation will fail if the workspace has cycles.
failIfNoMatch
- 預設值：false
- 型別：布林值
When set to true, the CLI will exit with a non-zero code if no packages match the provided filters.
For example, the following command will exit with a non-zero code because bad-pkg-name is not present in the workspace:
pnpm --filter=bad-pkg-name test