ワークスペース
pnpm には、モノリポジトリ(別名、マルチプロジェクトリポジトリ、またはモノリシックリポジトリ)のサポートが組み込まれています。 ワークスペースを作成して、単一のリポジトリ内で複数のプロジェクトを統合できます。
ワークスペースを作成するには、ルートに pnpm-workspace.yaml
を作成します。 また、ワークスペースではルートに .npmrc
を置くこともできます。
モノレポの管理を検討している場合は、Bit も検討することをお勧めします。 Bit は内部で pnpm を使用しますが、pnpm/npm/Yarn によって管理される従来のワークスペースで現在手動で行われている多くのことを自動化します。 bit install
に関するこちらの記事に、それについて書かれています: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. 例えば、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"
がワークスペースに存在しないため、インストールに失敗します。
このプロトコルは、link-workspace-packages オプションが 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 をサポートした、よくテストされたツールです。
Rush を使用してレポジトリをセットアップする方法については、こちらのページ (英語) を参照してください。
Changeset を pnpm と組み合わせて使用する方法については、こちらのガイド を参照してください。
トラブルシューティング
pnpm は、ワークスペース依存関係間に循環がある場合、スクリプトがトポロジカル順序で実行されることを保証しません。 pnpm がインストール時に循環する依存関係を検出すると、警告が表示されます。 どの依存パッケージが循環の原因となっているかわかれば、pnpm はそれを表示します。
There are cyclic workspace dependencies
といったメッセージが表示された場合は、dependencies
, optionalDependencies
, devDependencies
に定義された依存関係を調査してください。
使用例
pnpm のワークスペース機能を使用している特に有名なオープンソースプロジェクトのいくつかを以下に示します。