ワークスペース
pnpm には、モノリポジトリ（別名、マルチプロジェクトリポジトリ、またはモノリシックリポジトリ）のサポートが組み込まれています。 ワークスペースを作成して、単一のリポジトリ内で複数のプロジェクトを統合できます。
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. 例えば、bar が "foo": "^1.0.0" を依存関係に定義していて、foo@1.0.0 がワークスペースにある場合、foo@1.0.0はbarにリンクされます。 ただし、 bar が依存として "foo": "2.0.0" を定義しても、foo@2.0.0 がワークスペース側になければ、foo@2.0.0 はレジストリからインストールされます。 この動作はいくつかの不確実性をもたらします。
幸い、pnpmは workspace: プロトコルをサポートしています。 このプロトコルが使用されている場合、 pnpm は ローカルにあるワークスペースパッケージ以外のものに解決されることを禁止します。 そのため、 "foo": "workspace:2.0.0"を設定すると、今回は "foo@2.0.0" がワークスペースに存在しないため、インストールに失敗します。
This protocol is especially useful when the linkWorkspacePackages option is set to false. この場合、 workspace: プロトコルが使用されている場合にのみ、pnpm はワークスペースからパッケージをリンクします。
エイリアスを介したワークスペースパッケージの参照
たとえば、 foo という名前のパッケージがワークスペースにあるとします。 通常、 "foo": "workspace:*" として参照します。
別のエイリアスを使用する場合は、次の構文も使用できます: "bar": "workspace:foo@*".
公開する前に、エイリアスは通常のエイリアスされた依存関係に変換されます。 上記の例は "bar": "npm:foo@1.0.0" になります。
相対パスでワークスペースのパッケージを参照する
ワークスペースに 2 つのパッケージがあるとします:
+ packages
+ foo
+ bar
bar は foo を依存として "foo": "workspace:../foo" と宣言することができます。 公開する前に、こ れらのバージョン指定はすべてのパッケージマネージャーがサポートしている通常のバージョン指定に変換されます。
ワークスペースのパッケージの公開
ワークスペースのパッケージが (pnpm pack や pnpm publish などのコマンドを使用して) アーカイブファイルにパックされる際に、 workspace: プロトコルで書かれた依存関係を次のように変換します。
- そのワークスペースにある対応するバージョン (
workspace:*、workspace:~、workspace:^のいずれかのバージョン指定方法を使っている場合) - 対応する semver の範囲指定 (その他の範囲指定を使っている場合)
たとえば、 ワークスペースに 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"
}
}
この機能により、ローカルにあるワークスペースのパッケージに依存する指定を使用しながら、最終的にパッケージをレジストリに公開する際に追加の変換ステップを挟む必要がなくなります。あなたのパッケージの使用者は、公開されたパッケージを他のパッケージとなんら変わらないように使うことができ、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 はそれを表示します。
There are cyclic workspace dependencies といったメッセージが表示された場合は、dependencies, optionalDependencies, devDependencies に定義された依存関係を調査してください。
使用例
pnpm のワークスペース機能を使用している特に有名なオープンソースプロジェクトのいくつかを以下に示します。
