Skip to main content

Migrate from yarn to pnpm

· 2 min read


  • Yarn berry was all the rage.
  • I tried it and found quite a few problems, which is why I ended up choosing pnpm.



  • It stores all the packages and logs all the diffs. This is a major culprit for repository size. Difficult to manage images under 1GB.
  • If typescript goes up, yarn berry version should go up. I want to use the latest syntax in typescript right away, but I can't keep up.
  • I need to update the executable with yarn dlx @yarnpkg/sdks vscode whenever typescript, eslint, and prettier are released.
  • In a project with 20+ front-end developers, this is hard to enforce.
  • It is not possible to test this by making small changes to the source inside the package.


  • Monolithic tools like turbo, environments with postinstall hooks like prism, or preset configurators like create-* reference node_modules directly.
  • Often it won't even run, and you'll have to wait for an open issue in each repo. I'm not writing this to analyze yarn berry's pnp script.
  • In this case, I'd have to give it a nodeLinker and use it the same way I would with yarn 1, with no advantage.


  • The yarn workspaces feature is cool, and yarnpkg/berry is a perfect example of it.
  • But it's only cool if you're only developing node.js libraries. Libraries for the frontend need a bundler, and there's no reference for that.


  • Benchmark scores are managed by Pnpm on a daily basis.
  • Slowness is acceptable with pipeline cache and lock files enabled. It's a one-time slowdown, not a request/response slowdown, so it can be handled by probes anyway.


  • The plugin features in yarn berry are cool, but they add more stress to dependency management.