Bun support and/or migration

[hdodov]

As you might be already aware, Bun 1.0 just got released. I guess I'm not the only one who'll appreciate a magnitude of times faster Payload experience, so I'm going to start the inevitable discussion about Bun.

Currently, Payload is using the slowest bundler (Webpack). Bun is over 200 times faster. I'd like that. Quicker restarts in dev mode would also be greatly appreciated. On top of that, Bun is simply a more performant runtime, so there's that as well.

With Payload 2.0 right around the corner and Bun 1.0 getting released just yesterday, I acknowledge that a full-blown migration to Bun is probably not rational at this point, or even feasible. But I wonder if the Payload team is considering Bun some time in the future, perhaps when Payload can afford to move in a slightly different direction and after Bun has gained a bit more adoption.

Bun attempts to be a tool that cuts the bullshit and lets people be productive, focusing on the important things. Payload seems to have similar goals but in the CMS realm. It attempts to fix actual common pain points and provide the most juicy features. Being able to do that multitudes of times faster than the competition is only going to make Payload the ultimate CMS, in my opinion.

Would love to hear your opinions about a potential migration and Bun as a developer tool in general @jmikrut @DanRibbens @denolfe @JarrodMFlesch @jacobsfletch @JessChowdhury! 🙌

[Thisisjuke]

I like this proposition!
I think the major issue I encounter often is the local dev experience. Always trying to fix things relative to nodemon or ts-node, in the most ambiguous way you can think of it. I also think that Bun can be a huge patch to that. Not a replacement of an official configuration for ViteJS or SWC, but at least the common features will be included out-of-the-box: TS, TSX, Scss, fast performance, support of 100% of the tsconfig like aliases, etc.

But right now, there is this issue still open after Bun 1.0 release: oven-sh/bun#2450

As you can see, there still mandatory things that are not merge inside this 1.0 release 🤔

• Workspaces (so not compatible atm with NX and Turborepo)
• Windows Support
• MacOS full Support
• Issues with peerDependencies

Don't know when those issues will be resolved and if it will be done when Bun will be taken into consideration by the Payload community ✌️

[hdodov]

As an end-user, I was able to simply execute bun dev, rather than npm run dev, and my project ran without absolutely no issues! Although this didn't speed up my process a lot because Payload still uses Webpack internally. Using bun install also works perfectly, which is a pretty solid boost in speed, compared to npm install.

It seems that you can use Bun with Payload even right now, without anyone having to do anything, but the more significant gains still have to come from Payload switching away from Webpack.

[AlessioGr]

Keep in mind that you'll have to remove nodemon. In a fresh project, bun dev would run nodemon, which runs ts-node. Thus, bun isn't really used.

I've tried bun run --watch src/server.ts and that works perfectly.

As for bun install, I'm surprised that works for you. Bun currently does not support sharp's post-install scripts. When using bun install, I'm getting an error when trying to run the project.

[JarrodMFlesch]

@AlessioGr have you seen this issue/response in their Github? oven-sh/bun#4549 (comment)

[hdodov]

@AlessioGr ah, yes, I also got the error with Sharp on a fresh install. I tried bun install in a repo where I had already performed an npm install, so Sharp was already there.

I freshly cloned my project and as @JarrodMFlesch pointed out, adding this to my package.json fixed it:

{ "trustedDependencies": ["sharp"] }

…but because I had already done an install without it, I had to do this first:

rm -rf node_modules bun.lockb

After that, I got the following error, though:

$ bun run --watch src/server.ts     
[0.17ms] ".env"
[06:41:52] INFO (payload): Connected to MongoDB server successfully!
[06:41:52] INFO (payload): Starting Payload...

error: Cannot find package "functions-have-names" from "/Users/hristiyan.dodov/Projects/payload-test/node_modules/set-function-name/index.js"

I wonder why this package didn't get installed. It doesn't have post-install scripts like Sharp…

---

Anyway, in my main project with all dependencies set up, I can run bun run --watch src/server.ts and everything goes smoothly — Payload connects to the database, starts listening on port 3000, Webpack compiles… — but when I go to http://localhost:3000/admin, I get ERR_CONNECTION_REFUSED. If I run bun run dev (and go through nodemon and ts-node) it works, though.

But there doesn't seem to be any difference in performance, which is interesting. In fact, it's even slower:

• bun run --watch src/server.ts initializes Payload in ~3.4 seconds and compiles with Webpack for ~3.2 seconds
• bun run dev and npm run dev also initialize Payload in ~3.4 seconds, but compile with Webpack for ~1.3 seconds

[matthijs166]

@hdodov and just for comparison, how fast is it with just plain old npm?

[hdodov]

@matthijs166 as I said in my previous comment, the performance of bun run dev and npm run dev is essentially the same. You only get the few hundred milliseconds boost from bun run vs npm run, but nothing more after that. Running bun run --watch src/server.ts (which completely avoids Node) is actually slower somehow.

But that's in my project and on my hardware (Darwin 22.6.0 x86_64 i386). You should test for yourself. Results might be different.

[iamacup]

TLDR: Sharp i think is an easy fix - just needs bumping to 0.33.0 - but there is a problem with a shebang that i can't work out. I am also running inside of a mono repo and i do wonder if that is contributing to problems - i would be interested in community feedback on the shebang thing below.

I am fairly sure this explains why this approach @AlessioGr : https://github.com/AlessioGr/payload-template-bun/blob/main/Dockerfile fails without node installed.

Shebang

I thought i would add some stuff here because I don't think its quite as straightforwards as it seems.

It is relatively easy to get payload to run on bunjs (nodemon, dotenv etc. will still work but you should strip them) - however - there is some annoying default behavior of bun detailed here: oven-sh/bun#3417

Its not obvious because almost all users will have node and bun running on their shell, and there is silent fallback in bun to node - basically if there is a shebang, it will silently fork to node - which there is in the build step of payload.

#!/usr/bin/env node
require('./dist/bin')

I can’t tell if its a bug in bun, but if you use a clean container with just the bun runtime, the command bun payload (or bun --bun payload) will fail on

if (module.id === require.main.id) {
                   	^
TypeError: undefined is not an object (evaluating 'require.main.id')

This should not be a problem as require.main.id is supported by bun, but fiddling around with the shebang breaks it more - although i really am a bit over my head about the specifics of this or how to debug it further.

Now arguably you should not be using bun for production so this is kind of a moot point - who cares if the prod build step breaks - but its worth knowing for any work on this.

It is possible to get bun to build by replacing module.id === require.main.id with import.meta.main but this should not be required, something else is going on.

Here is my package.json scripts section in case anyone is looking for one that works with bun (you do not need tsc, you can run the typescript directly with serve) - this will force the shebang to resolve to bun so you should expect failures on generate:types, generate:graphQLSchema and build:admin:

  "scripts": {
    "dev": "bun --watch ./src/server.ts",
    "generate:types": "bun run payload-wrap generate:types",
    "generate:graphQLSchema": "bun run payload-wrap generate:graphQLSchema",
    "payload-wrap": "bunx cross-env PAYLOAD_CONFIG_PATH=src/payload.config.ts bun --bun payload",
    "build:admin": "bun run payload-wrap build",
    "serve": "bun ./src/server.ts"
  },

which can be fixed with something like this if you want to go wild:

  "scripts": {
    "dev": "bun --watch ./src/server.ts",
    "generate:types": "bun run payload-wrap generate:types",
    "generate:graphQLSchema": "bun run payload-wrap generate:graphQLSchema",
    "payload-wrap": "bun run fix-for-bun && bunx cross-env PAYLOAD_CONFIG_PATH=src/payload.config.ts bun --bun payload",
    "build:admin": "bun run payload-wrap build",
    "serve": "bun ./src/server.ts",
    "fix-for-bun": "replace-in-file 'module.id === require.main.id' 'import.meta.main' ./node_modules/payload/dist/bin/*.js"
  },

but again, i want to stress - this replacement should not be needed and i can't work out why it is. Bun does support require.main.id.

Fixing sharp

Add this:

  "resolutions": {
    "sharp": "0.33.0"
  },

details here: lovell/sharp#3511

i have had no issues with Payload running on 0.33.0.

[iamacup]

We also need to get sass-loader moved from 12.x to, ideally 14.x in webpack plugin to get rid of the fibers dependency - as there is a build step in 12.x which checks node version and obviously bunjs does not handle this well. This does not matter if using vite.