ワークスペース
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 のワークスペース機能を使用している特に有名なオープンソースプロジェクトのいくつかを以下に示します。
設定
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
- タイプ: Boolean
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
- デフォルト: true
- タイプ: Boolean
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
- デフォルト: 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
- タイプ: Boolean
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
- デフォルト: true
- タイプ: Boolean
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
- タイプ: Boolean
When executing commands recursively in a workspace, execute them on the root workspace project as well.
ignoreWorkspaceCycles
- デフォルト: false
- タイプ: Boolean
trueに設定すると、ワークスペースの循環参照警告は出力されません。
disallowWorkspaceCycles
- デフォルト: false
- タイプ: Boolean
When set to true, installation will fail if the workspace has cycles.
failIfNoMatch
- デフォルト: false
- タイプ: Boolean
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