Workspace (ruang kerja)
pnpm memiliki dukungan bawaan untuk monorepositori (repositori multi paket, repositori multi proyek, atau repositori monolitik). Anda dapat membuat workspace untuk menyatukan beberapa proyek di dalam satu repositori.
Sebuah workspace haruslah memiliki pnpm-workspace.yaml
di dalam folder akarnya. Sebuah workspace juga mungkin perlu memiliki .npmrc
di dalam folder akarnya.
Protokol workspace (workspace:)
Secara asali, pnpm akan menautkan paket dari workspace jika paket tersedia cocok dengan rentang yang dideklarasikan. Misalnya, foo@1.0.0
akan ditautkan ke bar
jika bar
memiliki "foo": "^1.0.0"
dalam dependensinya. Namun, jika bar
memiliki "foo": "2.0.0"
dalam dependensi dan foo@2.0.0
tidak ada di workspace, maka foo@2.0.0
akan diinstal dari registri. Perilaku ini memperkenalkan beberapa ketidakpastian.
Untungnya, pnpm mendukung protokol workspace:
. Ketika protokol ini digunakan, pnpm akan menolak untuk menyelesaikan apa pun selain paket workspace lokal. Jadi, jika Anda menyetel "foo": "workspace:2.0.0"
, kali ini instalasi akan gagal karena "foo@2.0.0"
tidak ada di workspace.
Protokol ini sangat berguna ketika opsi link-workspace-packages disetel ke false
. Dalam hal ini, pnpm hanya akan menautkan paket dari workspace jika protokol workspace:
digunakan.
Merujuk paket workspace melalui alias
Katakanlah Anda memiliki paket di workspace bernama foo
. Biasanya, Anda akan mereferensikannya sebagai "foo": "workspace:*"
.
Jika Anda ingin menggunakan alias yang berbeda, sintaks berikut juga akan berfungsi: "bar": "workspace:foo@*"
.
Sebelum dipublikasikan, alias dikonversi ke dependensi alias biasa. Contoh di atas akan menjadi: "bar": "npm:foo@1.0.0"
.
Merujuk paket workspace melalui jalur relatifnya
Di workspace dengan 2 paket:
+ packages
+ foo
+ bar
bar
mungkin memiliki foo
dalam dependensinya yang dinyatakan sebagai "foo": "workspace:../foo"
. Sebelum dipublikasikan, spesifikasi ini dikonversi ke spesifikasi versi reguler yang didukung oleh semua pengelola paket.
Memublikasikan paket workspace
Ketika paket workspace dikemas ke dalam sebuah arsip (baik itu melalui pnpm pack
atau salah satu perintah terbitkan seperti pnpm publish
), kami secara dinamis menggantikan setiap dependensi workspace:
dengan:
- The corresponding version in the target workspace (if you use
workspace:*
,workspace:~
, orworkspace:^
) - The associated semver range (for any other range type)
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"
}
}
Will be transformed into:
{
"dependencies": {
"foo": "1.5.0",
"bar": "~1.5.0",
"qar": "^1.5.0",
"zoo": "^1.5.0"
}
}
This feature allows you to depend on your local workspace packages while still being able to publish the resulting packages to the remote registry without needing intermediary publish steps - your consumers will be able to use your published workspaces as any other package, still benefitting from the guarantees semver offers.
Release workflow
Versioning packages inside a workspace is a complex task and pnpm currently does not provide a built-in solution for it. However, there are 2 well tested tools that handle versioning and support pnpm:
For how to set up a repository using Rush, read this page.
For using Changesets with pnpm, read this guide.
Options
link-workspace-packages
- Default: true
- 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.
prefer-workspace-packages
- Default: false
- Type: 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 save-workspace-protocol
.
shared-workspace-lockfile
- Default: true
- Type: 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
note
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.
save-workspace-protocol
- Default: true
- Type: Boolean
If this is enabled, new dependencies will be added with the workspace protocol IF (and only if) they are present in the workspace.
You might want to change this setting to false
if the tooling in your repository does not understand the workspace protocol (and ideally submit a PR to your tooling to get it added in the future).
Troubleshooting
pnpm cannot guarantee that scripts will be run in topological order if there are cycles between workspace dependencies. If pnpm detects cyclic dependencies during installation, it will produce a warning. If pnpm is able to find out which dependencies are causing the cycles, it will display them too.
If you see the message There are cyclic workspace dependencies
, please inspect workspace dependencies declared in dependencies
, optionalDependencies
and devDependencies
.
Usage examples
Here are a few open source projects that use the workspace feature of pnpm:
- icestark (as of 12/16/2021, commit
4862326a8de53d02f617e7b1986774fd7540fccd
) - Vue 3.0 (as of 10/9/2021, commit
61c5fbd3e35152f5f32e95bf04d3ee083414cecb
) - Vite (as of 9/26/2021, commit
3e1cce01d01493d33e50966d0d0fd39a86d229f9
) - Cycle.js (as of 9/21/2021, commit
f2187ab6688368edb904b649bd371a658f6a8637
) - Prisma (as of 9/21/2021, commit
c4c83e788aa16d61bae7a6d00adc8a58b3789a06
) - Verdaccio (as of 9/21/2021, commit
9dbf73e955fcb70b0a623c5ab89649b95146c744
) - Rollup plugins (as of 9/21/2021, commit
53fb18c0c2852598200c547a0b1d745d15b5b487
) - Milkdown (as of 9/26/2021, commit
4b2e1dd6125bc2198fd1b851c4f00eda70e9b913
) - ByteMD (as of 2/18/2021, commit
36ef25f1ea1cd0b08752df5f8c832302017bb7fb
) - VueUse (as of 9/25/2021, commit
826351ba1d9c514e34426c85f3d69fb9875c7dd9
) - Slidev (as of 4/12/2021, commit
d6783323eb1ab1fc612577eb63579c8f7bc99c3a
) - SvelteKit (as of 9/26/2021, commit
b164420ab26fa04fd0fbe0ac05431f36a89ef193
) - Telecraft (as of 9/26/2021, commit
73a9c48c9d4f160d758b8881f404cc52c20a7454
) - GiraphQL (as of 8/4/2021, commit
3dd3ff148da382d6f406f20626a9a5c25707c0c8
) - Tailchat (as of 12/27/2021, commit
298af71aa0619e0a8fa8717777afe2fb32739db4
) - Vitest (as of 12/13/2021, commit
d6ff0ccb819716713f5eab5c046861f4d8e4f988
) - Element Plus (as of 9/23/2021, commit
f9e192535ff74d1443f1d9e0c5394fad10428629
) - Astro (as of 3/08/2022, commit
240d88aefe66c7d73b9c713c5da42ae789c011ce
) - VuePress 2.0 (as of 4/23/2022, commit
b85b1c3b39e80a8de92a7469381061f75ef33623
) - NextAuth.js (as of 5/3/2022, commit
4f29d39521451e859dbdb83179756b372e3dd7aa
) - cz-git (as of 4/25/2022, commit
e59a5236a868549e027ff0b5e73b4db1212b7130
)