Move to a new package manager

[hdodov]

Link to reproduction

https://github.com/hdodov/payload/tree/yarn-version

To Reproduce

1. Clone the Payload repo

2. Run yarn with Yarn 3.5.0

3. You'll get this warning:

   YN0070: Migrating from Yarn 1; automatically enabling the compatibility node-modules linker 👍

   And you'll also get a new .yarnrc.yml file, among other things. Check hdodov@fcf5588.

Describe the Bug

The project seems to be based on an outdated Yarn version. I get the aforementioned warning using either Yarn 3 or 4. That's an issue because it makes it harder to set up a reproduction branch for a bug. If I want to merge my branch with the upstream Payload branch, I'd get conflicts, because the upstream branch uses an old lock file.

Payload Version

1.7.0

[jmikrut]

Hey @hdodov — I just spoke with the team about this and I think that we will need to be very deliberate about which package manager we decide to adopt. But as this is not an issue, per se, I have converted it to a Discussion and tagged it as Roadmap Priority 2.

That way we can be more judicious / explicit about our choice - whether it be a newer version of yarn, pnpm, or just good ol' npm.

What would your vote be?

[hdodov]

I personally use npm in my project and haven't experienced issues. However, pnpm can also be a viable option if you want to handle monorepos, as @mattddean suggested.

But I don't think that Yarn has any huge benefit over npm anymore. It used to be a lot faster, but npm in its latest versions has caught up, I believe. It works great for our team, at least.

[mattddean]

I think that the general consensus is that pnpm is the best package manager if you're going to do anything monorepo-related. Being able to easily support monorepos out of the box is a big win for anyone using Payload Cloud who wants to deploy their frontend on something like Vercel and Payload on Payload Cloud. Undoubtedly, in doing that, you're going to run into some shared dependencies (like react being required by both projects), but want to manage the versions of those dependencies separately. pnpm is really good about letting you specify different versions of packages for different projects within the same monorepo.

[tim-the-arcane]

+1 for pnpm and monorepo compatibility. This would be a huge win for us!

I think it would also fix the problem with the --legacy-peer-deps flag being necessary in Docker Compose to use it in a fresh install

[dawidmachon]

+1 for pnpm and monorepo compatibility.

[DasMergo]

+1 for pnpm

[miguelvictor]

+1 for pnpm!

[silveltman]

+1 for pnpm
+1 for bun

My usecase: one app in my monorepo required node18, but payload cloud does not support node18.

[fa-bwilliams]

+1 for pnpm
+1 for bun

[mrienstra]

Edit: oh, ha, this move already happened (Aug 22nd)! #3128 -- maybe this discussion should be closed? https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-discussions#closing-a-discussion

---

Some yarn --> pnpm migration PRs:

Vue: vuejs/core#4766
Next.js: vercel/next.js#37259
Vite: vitejs/vite#5060
Pinia: vuejs/pinia#1179
Cycle.js: cyclejs/cyclejs#821
Verdaccio: verdaccio/verdaccio#1884
Element Plus: element-plus/element-plus#3571
Agora Flat: netless-io/flat#1442

yarn --> pnpm migration commits (couldn't locate PRs):

Browserlist: browserslist/browserslist@6d0c552
PostCSS: postcss/postcss@ec80417

Also using pnpm:

SvelteKit: https://github.com/sveltejs/kit
Prisma: https://github.com/prisma/prisma
Nhost: https://github.com/nhost/nhost

Yarn 4 was released about 3 weeks ago, huzzah! I haven't had a chance to play with it, or find out how others are getting on with it. This was an interesting skim: https://news.ycombinator.com/item?id=37985779

---

Note: above is largely copied from microsoft/vscode#162803, with the follow updates:

1. Quickly verified that all of the repos listed above as using pnpm are still doing so (superficial check: they all still have ./pnpm-lock.yaml files)
2. Updated the Yarn 4 section

[denolfe]

The Payload repo moved to a pnpm monorepo for the 2.0 release.

[silveltman]

Does this mean payload cloud also supports pnpm? I'm not that experienced with bundling 😬

[bsides]

When I use pnpm create payload-app@latest, which option reflects this? Because the payload-demo one still tries to install dependencies with yarn

[ceyhun-yildiz]

+1 for pnpm
+1 for bun

[hdodov]

@jmikrut now that Payload is Next.js-native in version 3, it makes sense to me to use npm. That's what Next uses and pushes in its documentation (all examples use npx or npm).

It'd be great if a Payload project was just another Next.js project. That's currently not the case. The entanglement with pnpm introduces quite a lot of friction, especially when you throw Docker in the mix.

If Next was primarly pnpm-oriented — great — but it's not. Since Payload is built on top of the Next platform, it makes sense to use whatever the platform works best with, no?

[Abhid14]

I feel payload should be package manager agnostic or could support more package managers. As I use bun as a package manager it has very positive impact on my build times. Using pnpm is much slower than bun at build time.