Replies: 4 comments 5 replies
-
I like this proposition! 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 🤔
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 ✌️ |
Beta Was this translation helpful? Give feedback.
-
As an end-user, I was able to simply execute 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. |
Beta Was this translation helpful? Give feedback.
-
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. ShebangI 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.
I can’t tell if its a bug in bun, but if you use a clean container with just the bun runtime, the command
This should not be a problem as 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 Here is my
which can be fixed with something like this if you want to go wild:
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 sharpAdd this:
details here: lovell/sharp#3511 i have had no issues with Payload running on 0.33.0. |
Beta Was this translation helpful? Give feedback.
-
We also need to get |
Beta Was this translation helpful? Give feedback.
-
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! 🙌
Beta Was this translation helpful? Give feedback.
All reactions