ワークスペース
pnpm には、モノリポジトリ（別名、マルチプロジェクトリポジトリ、またはモノリシックリポジトリ）のサポートが組み込まれています。 ワークスペースを作成して、単一のリポジトリ内で複数のプロジェクトを統合できます。
A workspace must have a pnpm-workspace.yaml file in its
root. A workspace also may have an .npmrc 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 link-workspace-packages 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 link-workspace-packages 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 のワークスペース機能を使用している特に有名なオープンソースプロジェクトのいくつかを以下に示します。
