Native bun support - significant speed increases possible. #21075
Comments
|
Amazing work! I really hope this gets accepted. My gut tells me that Bun isn't just hype. When Yarn came out, it was also hyped. And that hype made NPM almost as fast as Yarn as a response. But this time, there doesn't seem to have been a response from the Node team. It seems like they don't want to do a lot about the performance in comparison to what Bun is doing. Windows support (as of today) is 33% done (33% of tests are passing according to the Bun X profile, for Windows). I honestly think that NX is amazing. But if Bun doesn't get supported within the next year or so, I think we'll switch to a monorepo tech that supports it. |
|
Have you validated the output? They have been issues where the output didn't match what npm and node was doing. Sometimes it claimed it ran without it actually running. I have a benchmark between the two with full nx bun support. It wasn't until we validate the output did I notice it was incorrect. |
|
Amazing! |
|
@gunta - There is a crash when creating the Docker, basically an undefined inside of nx when I try to build the targets:
Full details here: https://github.com/bhouston/template-typescript-monorepo/actions/runs/7476266475/job/20346266765 |
|
@Jordan-Hall wrote:
The template project I have linked to multiple times definitely is working well, even though it compiles in 30% less time. My production app, which I cannot share, has hundreds of unit tests and they are passing with bun, even though the compile time is 4x faster. And the app appears to work as well when using it. So if there are differences they are small enough that I have not yet noticed them. |
|
@ffMathy wrote:
Node tends to respond but very slowly. I remember when IO.js project arrived and it caused change in the Node.JS community. Yarn pushed Node/NPM to change as well, but it took like 4 years. Node/NPM is still not dealing with mono repositories properly. Even though mono repositories are the main way to work for the last 5 years. Maybe Bun causes Node to change here. One of the major differences is that Bun uses the Safari JavaScript engine, JSC, where as Node uses the Chrome JavaScript engine V8. That is a major change and I am not sure Node is willing to make that change and it would break backwards compatibility at the low level. Maybe Chrome somehow adopts better JS execution technology in their JS engine? That could also close the gap. |
|
@Jordan-Hall wrote:
Can you share it? Are you sure that it wasn't another bug? I've found that bun works properly. Now, I am not using bun's typescript compiler/transpiler, I am just using it as a runtime replacement for node.js and npm. I found that because Bun is just faster, this is enough for me. |
|
It was a while ago I'll update repo and test it. I'm using nx-bun plugin I wrote but the issue was found to be related to bun install. It wasn't doing soemthing correctly when installing but not crashing. The bun team was aware because we was all shocked but the result https://github.com/Jordan-Hall/large-ts-monorepo-node-bun |
|
.@AgentEnder I don't mean to troll, but why are you guys fighting the tide? |
|
Happy to bring this back but again I personally think bun belongs to Nx labs atm like deno use to be, and thats more use at own risk. @AgentEnder would that be better? Plus with plugin package maybe allow plugins to handle package install and lock checking etc like it would be if manually added |
Bun support for windows is delayed. Many issues still outstanding, I also think it's still more of a hype as a runtime. Maybe not as a package manager but a full install including a runtime is kinda bad image :/ my 2 cent |
Unless launchweek has some bun announcement you really are putting Nrwl on the wrong side of history here @AgentEnder.
If Nrwl is waiting for "inbox 0" on bun's issue count, this perfectionism will make Nx an also-ran (and that perfectionism includes waiting for windows support). |
|
Waiting for windows is must and it's not zero. They many many bugs thats stops it being used in production. Look at comment above about the large repo |
Eh I agree to disagree whether windows is a must for an asterisked/labs release. People stuck on windows have wsl, docker etc if they are desperate for bun, nobody is saying bun should be a default in order for its usage to start.
People ideally rebundle things for prod anyways, rather than e.g. deploying react with nestjs+storybook+jest code (same for nest). Or for workers and lambdas you might be shipping minimized js and that's it. As long as the compile output is sane/legit js ✔️ and the bun side of build tooling works well ✔️ , then the prod deployment is a separate concern imo. |
This isn't always the case though! They not outputting the same! but also no error on the output! |
don't doubt it's happened plenty of times. and in retrospect would kinda undermine my point re the build experience. failure-to-build hasn't hit me badly enough, and earlier on for production bun def shouldn't be the golden path yet, but nobody wanting to use it thinks it's perfect. just that it's often perfect for their cases. I'd also emphasize that a bun monorepo wo/nx is often a nicer experience then an nx monorepo wo/bun and that's a major thing to consider (depending on size of repo of course). |
|
@AgentEnder FYI, we (Threekit) have contracted with your company formally to help migrate a large repository to NX. That migration doesn't yet include bun, but we know from our tests that adopting bun would lead to significant build speed increases. |
Worker and worker_threads are unreliable in Bun right now. They also issues around not finding packages which could be related to this. |
|
Just going to log a couple of mores found with bun thay could leads to issues on NX side and not bun. Duplicated exports (this isn't just an issue with circular dependencies) oven-sh/bun#7521 |
|
@FrozenPandaz I'm happy to get bun support in once #22602 been merged. We could have a bun package however most of node will work in bun but node wont work in bun. I believe it best if a runtime package is added? Also bun test is easy to add once its been decided on the approach for bun |
Bun uses yarn lock for it's binary file. Running the binary will produce the content of a yarn lock file (v1) Other option is to use the -y command on add and install. This will create a yarn lock file and then createLockFile can just modify the yarn.lock file instead? This is the PR made from #19113 and pushed due to #22402 being closed. PS Bun feels more stable since the PR was first created! This PR will resolve #22283 and start of #21075
|
This issue has been automatically marked as stale because it hasn't had any activity for 6 months. |
Description
Bun has been an often requested feature for NX see here:
Previously, it was not prioritized/accepted because Bun was pre-release. But Bun is now > 1.0. So now would be the time.
Motivation
I've done some tests by attempting to manually get most executors to run using bun in this template (TypeScript + React/Vite + Koa Server) mono repository setup with NX.
Using node.js + npm both on the latest, I get these build times:
(from here: https://github.com/bhouston/template-typescript-monorepo/actions/runs/7469814936)
If I switch to my hack in of bun, I get these much improved build times:
(from here: https://github.com/bhouston/template-typescript-monorepo/actions/runs/7476000610)
That is nearly 30% faster and this isn't even a complex project. I have a production project with a nearly identical setup (but a lot more code) and I am seeing a 4x speed up when it comes to running build + test. The degree of speed improvement cannot be ignored - 4x is absolute insane and generally unheard of.
My hack of bun into my template repository can be found here - you can run it locally easily:
bhouston/template-typescript-monorepo#12
My docker build fails in the CI though because my hack obviously isn't enough and I Think it is trying to use npm/node inside of NX and in the docker build that isn't available.
Suggested Implementation
I think that one could allow bun to be specified as the package manager similar to how npm, yarn, etc are specified. And ensure that NX can build properly in Docker and make it so I do not have to hack in using bun/bunx everywhere.
Alternate Implementations
I am not sure. If you wanted to you could just figure out why NX crashes during the docker and I can then use this bun hack in production fully.
The text was updated successfully, but these errors were encountered: