Native bun support - significant speed increases possible.

[bhouston]

Description

Bun has been an often requested feature for NX see here:

• https://github.com/nrwl/nx/issues/19093
• https://github.com/nrwl/nx/issues/11049
• https://twitter.com/gunta85/status/1740683268050330061

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:

https://github.com/bhouston/template-typescript-monorepo/pull/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.

[ffMathy]

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.

[Jordan-Hall]

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.

[gunta]

Amazing! If any issue arises on Bun side we should report them. The Bun team has been quite responsive.

[bhouston]

@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

[bhouston]

@Jordan-Hall wrote:

Have you validated the output?

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.

[bhouston]

@ffMathy wrote:

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.

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.

[bhouston]

@Jordan-Hall wrote:

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.

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.

[Jordan-Hall]

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

[guzmanoj]

.@AgentEnder I don't mean to troll, but why are you guys fighting the tide? This is the coolest s*** in the Universe right now!

[Jordan-Hall]

https://github.com/nrwl/nx/pull/19113

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

[Jordan-Hall]

.@AgentEnder I don't mean to troll, but why are you guys fighting the tide? This is the coolest s*** in the Universe right now!

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

[ludicast]

.@AgentEnder I don't mean to troll, but why are you guys fighting the tide? This is the coolest s*** in the Universe right now!

Unless launchweek has some bun announcement you really are putting Nrwl on the wrong side of history here @AgentEnder.

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

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).

[Jordan-Hall]

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

[ludicast]

Waiting for windows is must and it's not zero.

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.

They many many bugs thats stops it being used in production.

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 :heavy_check_mark: and the bun side of build tooling works well :heavy_check_mark: , then the prod deployment is a separate concern imo.

[Jordan-Hall]

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!

[ludicast]

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 bunx esbuild gave me the speed/stability I needed (unimplemented node apis in that case) for those things. but silence/inconsistency is bad, yeah.

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).

[bhouston]

@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.

[Jordan-Hall]

@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.

[Jordan-Hall]

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) https://github.com/oven-sh/bun/issues/7521 Relative paths in browser build https://github.com/oven-sh/bun/issues/6553 this doesn't actually link to sourcemaps seem to break in general. Bundling also doesn't seem to bring in node modules correctly unless it's hacked by code spliting

[Jordan-Hall]

@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