great deduplication of dependencies -> much less disk space used
stricter scope for dependencies
Cons:
Podfile needs to use custom script to resolve location of CLI dynamically as it is inside virtual-store (this has already landed in RN 0.72)
Gradle scripts need to use similar approach to resolve the location of CLI dynamically
Re.Pack output is a little bit harder to read as some paths now refer to pnpm's virtual store instead of nearest node_modules (potentially fixable but shouldn't be an issue).
Checklist:
[x] - fix typecheck
[x] - fix lint
[x] - fix tests
[x] - replace yarn with pnpm in docs
[x] - fix lint setup in remaining packages
[x] - add helper scripts for gradle & pods
[x] - make mocks more reusable within monorepo
[x] - add pnpm version to package.json in root of the monorepo
[x] - add section in docs about pnpm - why it's used, how to install it (link) etc.
Benchmarks
Tool
real time
user time
sys time
Disk Space
yarn berry
412.93s
24.96s
102.67s
3577MB
yarn berry (pnpm)
11.5s
8.8s
14.07s
578MB
pnpm
7.34s
4.37s
16.23s
528MB
Notes:
results after git clone and installing dependencies
for yarn the installation phase is very quick, but the linking phase takes 95% of it's time
yarn is using hoisitingLimits: workspaces
pnpm is using the default setting for node-linker: isolated
sys time greater than real time indicates using multiple threads to finish the operation (pnpm uses --workspace-concurrency=4 by default)
Summary
Why pnpm? https://pnpm.io/motivation
Pros:
Cons:
pnpm's virtual store instead of nearestnode_modules(potentially fixable but shouldn't be an issue).Checklist:
yarnwithpnpmin docspackage.jsonin root of the monorepoBenchmarks
Notes:
git cloneand installing dependenciesyarnthe installation phase is very quick, but the linking phase takes 95% of it's timeyarnis usinghoisitingLimits: workspacespnpmis using the default setting fornode-linker: isolatedpnpmuses--workspace-concurrency=4by default)