Suggestion: Use pnpm instead of yarn

Hi guys

I have been using pnpm since the last several months. It is simply superb

  • very fast
  • no need to do any workarounds. If you visit yarn issues, developers often keep asking about the workarounds.
  • takes less space than yarn and npm.

Read more about this:

I have seen many github repositories switching to pnpm since the last several months.

Hi @ramandhingra

Have you been using pnpm with Redwood? If we we’d be very interested in hearing how you set that up :slight_smile:

RW is working on moving RW Apps over to yarn v3, which will provide a much nicer end-user experience than what yarn currently does. You can follow along here:

Hi @Tobbe

I have not used pnpm with Redwood so far. Let me set it up, the setup is very easy. Will let you know after few hours.


These notes will help you replace “yarn” with “pnpm”

a. Remove lerna.json and yarn.lock

b. In the root’s’ package.json, add this:

"workspaces": [

c. When you use pnpm on a project, you don’t want others to accidentally run npm install or yarn. To prevent devs from using other package managers, you can add the following preinstall script to your package.json:

  "scripts": {
    "preinstall": "npx only-allow pnpm"

Now, whenever someone runs npm install or yarn, they’ll get an error instead and installation will not proceed.

d. Create a file name, pnpm-workspace.yaml in the root with the following contents:

- 'packages/*'

e. Install the dependencies
cd redwood
pnpm --ignore-scripts install

f. Add a dependency module using pnpm
pnpm add express Save to dependencies
pnpm add -D express Save to devDependencies
pnpm add -O express Save to optionalDependencies

g. When adding, removing, or updating dependencies within a workspace, you need to go that workspace’s folder first
cd packages/api
pnpm add csurf cookie-parser

cd packages/web
pnpm remove react-hot-toast

h. Run a script defined in the package’s file from the command prompt:
pnpm run *script-name*

i. Replacing ‘yarn’ commands with ‘pnpm’ in the pakage.json

yarn lint ---> pnpm run lint
yarn jest ---> pnpm run jest

j. Replacing ‘lerna run’ and ‘lerna publish’ commands with ‘pnpm’ in the pakage.json, these links may help

When you install Node > v 16.11.0, a corepack binary is included in the Node package. When you run ‘corepack enable’ it installs the yarn and pnpm. No need to install them explcitly… even if you try to install them explcitly after enabling corepack, it will report an error.

Do not use yarn either its classic stable 1.22.15 Or berry version 3.x. It has lots of issues especially if you use yarn workspaces for managing the monorepo.

Both pnpm and yarn support monorepos. However, there is a big difference between how they store dependencies in monorepos. Yarn tries to hoist all dependencies from all workspace packages into the root node_modules of the monorepo, which means that packages have access to dependencies of other packages in the workspace.

The pnpm stores all dependencies in a hidden folder named .pnpm under the workspace-root’s node_modules folder (i.e. redwood/node_modules/.pnpm) and only links the direct dependencies of every package into their node_modules. For example, when you install the dependency “express”, it will be visible to you in the busines/node_modules folder but its dependencies are hidden. pnpm downloads the dependency once and then link it wherever it is needed.

Kindly have a look at this blog too before you decide to go for yarn 3

Hi @ramandhingra, this is all really interesting and helpful information! Firstly, I want to make it clear there’s a separation for us (as maintainers) between the Redwood Framework (the GitHub repo with codebased for Redwood packages) and instances of Redwood Projects (e.g. an app you may be building with Redwood).

When we merge #4444, we think there’s a great chance you can use pNpm with your Redwood Project.

We already use Yarn 3 for the Redwood Framework and it has been working well (a massive improvement from Yarn 1). We’ve a collaborative relationship with the Yarn maintainters, which is also a benefit. Because Redwood has been in development since 2019, and used workspaces from the start, there are fundamental changes we’ve been continually making to improve how packages handle dependencies and binaries. It’s a hard, nuanced problem — the point being that there are no simple switches to flip for projects of Redwood’s size and complexity.

BUT for Redwood Projects, those fundamental package dependency and binary issues have been in the way of using anything except for Yarn 1. By the end of this week, via a preview feature, Redwood Projects will be able to switch to Yarn 3, which will be a massive gain in package stability and DX. (However, this will still require node_module use because of fundamental @redwoodjs package structure. The alternative is Yarn’ s pnp, not to be confused with pNpm.) We know it works and how to maintain it. And we understand its cross-platform compatibility.

All that said, the fundamental changes we made to get Yarn 3 working for Redwood Projects should likely be a benefit to projects that want to try pNpm. As long as workspaces are supported (which is also true of npm), we’re hoping the iimprovements will give devs the opportunity to choose which package manager they prefer. We won’t be able to support them all out of the box. But we’re hoping to reach basic compatibility.

Would you be able to try out pNpm with your project and let us know how it goes?

1 Like

Thanks @thedavid . I got your point very well. I will surely try out pnpm and let you know the outcome.

Pl. tell me how can I use the Express / Fastify middleware while running Redwood serverless. Is there any way out?

1 Like


And check out :rocket:

Hi @ramandhingra Can I ask what your use case for middleware is?

@dthyresson @thedavid

I have created a new thread for discussing CSRF. Here is the link: