Support for Bun - Preparedness to support different underlying runtimes/bundlres/test runners.

[mxa0079]

There has been a lot of noise around the beta release of Bun. The runtime looks very promising and complete (runtime, bundler, transpiler, and package manager all in one). It replaces node (or deno), webpack, and yarn (or npm).

• What does support for bun in nx looks like?
• Is it something in the mind of the core team?
• How would it co-live with current dependencies (like webpack or babel)?
• Could it live side by side, or would it be a replacement?
• What level of maturity does Bun needs to be considered by the core team?

[mxa0079]

Follow up on this discussion – Bun is the latest on a trend to create tools to manage Javascript projects, but that are not built for Javascript themselves. The obvious/biggest reason for this change is performance. These tools are built using languages that provide better performance (like Rust or Zig). It will be difficult for JS-based tools (or runtimes) to compete or keep up against these tools.

The overall arching question about this discussion is:

What is NX`s stand regarding this trend? Is NX prepared for this future? (e.g. swapping dependency on webpack or babel)

[AgentEnder]

Theres a few things to unpack here when thinking about the level of support in Nx for tooling, and what can currently be accomplished by the community vs things which aren't pluggable without changing Nx source code.

• Bundler
  • This would just be an executor, similar to @nrwl/web:rollup. A community member could create a plugin for bun today, that would execute bun bun.
• Runtime
  • For running code that people write inside Nx, this would also just be an executor similar to @nrwl/node:node A community member could create a plugin for bun today, that would execute bun run.
  • Swapping out the runtime that Nx uses internally would be a larger lift, but wouldn't benefit consumers of Nx in most cases. We may do it someday, but there would need to be a considerable reason to do so.
• Package Manager
  • This is the piece that can't easily be swapped out by a community plugin so far. The infrastructure is there, we can add package managers pretty easily as we currently support npm/pnpm/yarn, but its not something that's pluggable without source changes. We may add support for bun at some point, but currently bun is labeled as experimental. Its syntax for installing packages, running scripts, etc may all change and that adds a maintenance overhead on our end.

There's not anything certain I can say for what level of maturity would lead to us taking action on bun, but currently (as labeled in the readme),

bun is experimental software

[Jordan-Hall]

I want to address the "Runtime" this isn't a big issue as bun has built in support for swapper out #!/usr/bin/env node with #!/usr/bin/env bun by using either bun --bun or bunx --bun

This actually makes changes much easier than it would be to run NX completely in deno.

Open Issues:
Bun does not currently support IPC which causes issues with both nx-cloud and nx default task runner. Current approach swapping it out child-processor with worker (as recommended by Bun developer team)

The major issues that prevents full is the package manager. I think #15622 would be a better solution than adding it directly into nx and would provide more flexiablity in the future

[Jordan-Hall]

@AgentEnder I forgot to mention bun install --yarn this will create yarn lock file that could be parsed with already existing logic.

Using custom graph is they anything that can done to parse the bunlock or is it out the limits of plugins?

[asinino]

This is a duplicate of #11049 which states bun needs more time to mature before it is considered as a replacement.

[mxa0079]

Hello @asinino - thanks for the reply. I see discussions and issues as different tools with different objectives. An Issue implies an expected action from the maintainers. A discussion`s objective, as it name implies, is to stir a conversation.

In this regard, the most important question about this discussion is:

What is NX`s stand regarding this trend? Is NX prepared for this future? (e.g. swapping dependency on webpack or babel)

[ild0tt0re]

Is bun ready yet?

• Nodejs API:
  https://bun.sh/docs/runtime/nodejs-apis
• Package Manager (bun install): Is bun install ready yet? oven-sh/bun#2450

[Jordan-Hall]

I've started on experimental bun support with bun install and task runner https://github.com/Jordan-Hall/nx-bun Currently supports bun create and run. Will add bundle is shortly

[Jordan-Hall]

Sorry for spam on this. Last comment for now, I think it would be extremely useful for all node API to be imported with "node:..." such as import path from "node:path" this explicitly would be useful as it appears all new runtime are going to support node

[benbot]

Bun is 1.0 now :)

[Jordan-Hall]

They three issues with PM I believe

NX in the graph actually writes to the lockfiles itself, and they no real way of writing to it without recompiling to the binary (if you allow NX to write to lock file)
#19113

However, the lock file is just a binary form of yarn v1 which also contains a hash at the top in the comment
# bun ./bun.lockb --hash: E9BE4C8AFE26D7DC-86499c2c6695a57f-AF1AA6E155A780BF-6a5deb2df1b3afe9

The second issue for NX is determining if they should support bun package manager directly when not supporting bun directly. The other option would be to support 3rd party package manager via plugin #15622 which would be a better solution than supporting it directly until they ready to support bun themselves.

Then you have NX cloud issues. To use cloud you have to use https://github.com/nrwl/ci/blob/main/.github/workflows/nx-cloud-main.yml, however this doesn't support (to my knowledge) custom install commands

[StalkAltan]

You don't need to use the reusable workflow to use Nx Cloud -- it's just a good jumping off point for most installs that don't need anything extra. If you want to use bun install in your pipelines today (and you don't need lockfile features, so just want the install speed then invoke with Node as normal) I wouldn't expect there to be any problems.

[Jordan-Hall]

100% agree you dont, but it would be odd if you add PM into NX but not in nx-cloud which is what i was referring too.

[ffMathy]

@Jordan-Hall are we tracking the progress of integrating Bun's package manager in NX? You mention it is being discussed. Would be awesome to follow this as it unfolds.

[Jordan-Hall]

They so many issues inside bun atm but not sure where there are tracking it (not part of nx here)

However take a look here https://github.com/Jordan-Hall/nx-bun-template first repo to be full bun no node.

[travissimon]

I just wanted to throw in 2 cents from the cheap seats: I too am very interested in Bun, especially for runtime support and would like to add my encouragement for the nx team to continue investigating. Not meaning any disrespect to Jordan Hall, but I am not familiar with his development, and would generally trust a native (supported) NX solution/option more. Anyway, love your work :-)

[Jordan-Hall]

I stay quiet so not surprised no harm feeling here :) Personally most things I do I prefer to end up in main repo. Why i helped out on nxext so much and pushed for vite before it went into the repo.

However the team is correct here, Bun still extremely young, not popular and its on the hype bandwagon atm (like deno was) If anything bun will like end up in labs for ages. No point investing time on something thats not proven yet. It still has many bugs, rapid development and windows issues. The claims its node compatible isn't quiet true either. It will likely end up slowing the NX development down, for something only a few people will use.

Also doesn't help when Bun docs are not upto date and incorrect

[khushal123]

This would be awesome as a local alternative to nodejs, right now it's missing a lot of node APIs. However the speed is insane, I have been using it for only 2-3 days.

[Jordan-Hall]

Bun 1.0.2 has majority what u need for local bun instead of node. But seems like an issuenwith @nrwl/js:tsc it doesn't produce a output folder

[edunomatseye]

Bun is a new JavaScript runtime, bundler, and test runner that is still in its early stages of development. It is a promising project, but it is also controversial.

Some people believe that Bun is too ambitious and that it is trying to do too much. They argue that it is trying to replace a number of well-established tools, such as Node.js, Webpack, and Jest.

Others believe that Bun has the potential to be a major player in the JavaScript ecosystem. They argue that it is a more modern and efficient way to develop JavaScript applications.

Only time will tell whether Bun will be successful. However, it is a project worth keeping an eye on.

[Jordan-Hall]

Just thought i'll provide an update to @nx-bun/nx package (https://github.com/Jordan-Hall/nx-bun) Every new version now will be migrated. They just 1 PR to fix to add build target (But that will not affect 99% of users wanting to use bun) The only thing holding it back to submit to nx registry and version 1 is testing. All done manually, so this is being worked on.

Following that the following is being added in order

• convert to bun
• new custom task runner to use more of bun API than node

[Jordan-Hall]

No need for custom task runner (unless it to use pure bun api - pointless) bun 1.0.2 now allows nx run in bun runetime

[TkDodo]

is it possible to write a custom executor that uses the Bun apis, e.g. to read files?

[TkDodo]

so what we have is a custom executor, say:

"do-something": {
  "executor": "@company/do-something"
}

now this do-something executor currently spawns another task with spawn from 'child-process'. I wanted to see if I could replace that with Bun.spawn, but when I do that and I do:

nx run my-package:do-something

I get the error: Bun is not defined

My guess is that's because nx run doesn't run with bun, so my question was how I can achieve that? Do I need the nx-bun executor for that?

looking at this:

• https://jordan-hall.github.io/nx-bun/docs/nx-bun/executors.html

it seems that I could use the @nx-bun/nx:run executor to run a ts or js script with bun, but I'd still want to have that encapsulated away in a custom executor.

So I wouldn't know how to do that. Am I missing something?

[Jordan-Hall]

You can use that to run bun run using ts and js. If you want to wrap additional around it, if you look st the init generator you will see how you can call it.

Happy to help to. Are you on discord so we can talk better

[AgentEnder]

I just want to chime in real quick and say that if going this route its worth being aware of a few things:

• Nx doesn't currently support running bun as the runtime that Nx itself runs in. I don't see this changing anytime soon, but it shouldn't affect anyone developing projects within Nx
  • This means that generators, executors, or other pieces of Nx plugins will not be able to use bun APIs.
• If bun does happen to "just work" for Nx, thats really cool, but its still not something we would be actively supporting. This would make it super hard to deal with issues should they crop up.

[Jordan-Hall]

100% agree especially with issues I've found with bun and nx already.

I have no real intention of supporting bun runtime in nx too. I have too much respect for your lot.

It's in v1 all tested etc and works but nah. I'll provide patch files if people want to do it themselves but that's it

[TkDodo]

Happy to help to. Are you on discord so we can talk better

yeah I'm TkDodo on Discord as well.

[GraemeF]

Just thought I'd chime in as I've been using bun as a package manager for a couple of weeks. It mostly works, the only thing I've noticed is that nx doesn't detect package changes when working out what's affected:

The affected projects might have not been identified properly. The package(s) @playwright/test, browserslist, @effect/schema were not found. Please open an issue in GitHub including the package.json file.

Presumably nx needs a npm/yarn/pnpm lockfile for that - maybe generating a yarn lockfile from bun will help.

[Jordan-Hall]

Here you go this is a gist I made to help people https://gist.github.com/Jordan-Hall/e910402a31b4a1e5a0b78324d6595618

However @nx/js:tsc doesn't produce a output fist

[ffMathy]

When will this be released into nx?

[ludicast]

Any update on interest here from the nrwl side @AgentEnder / @StalkAltan ? Bun has definitely tipped over into the mainstream by this point and really worth revisiting.

[Jordan-Hall]

Nope, windows still mainly use WSL also has limitations including bun use.

[ffMathy]

It now has Windows support, right?

[ludicast]

I think via WSL. I read on Jarred's twitter that once full windows support is here they will be bumping Bun to 1.1.

Either way, it seems that there is no interest from nx in actually supporting bun in the first place. Which is really weird if they want to stop losing devs to other (inferior) monorepo tools - most of which loudly trumpet their bun support.

(yes yes we all know that bun is still a WIP but that doesn't really matter as it would be opt-in).

[ffMathy]

@ludicast ah I see.

Yeah, agreed. Speaking of which - do you know any monorepo tools that support Bun? Right now we have are not tighly dependent on NX, so we're in a situation where we'll switch.

[ludicast]

I know turborepo and moonrepo do. Also bun workspaces on their own (obviously).

I'm similarly not tightly-coupled to nx. But still prefer nx so crossing fingers and using a super scaled-down & pluginless version of it in a bun-first monorepo. Not perfect but don't want to switch and just switch back again in 6 months.

[bhouston]

I've been hacking in bun, now that it is 1.0, into my nx setup and it is resulting in a 4x speedup on my production projects and a 30% speed up on my public template project. I've documented this in this feature request which has a full reproduction and numbers:

#21075

Supporting bun moves NX up to the next level in terms of build and test speed. It is a no brainer from my perspective since it is mostly a drop in replacement for node execution wise.

[cyrsis]

If Nx support Bun , that monorepo finally can be use, otherwise sit for 5 mins for yarn

then screw up with conflict , wait for an other 5 mins

[Jordan-Hall]

So i have got a patch to allow all of NX to use Bun package manager too, however i want to again stress using --bun to force all onto bun runtime has issues including most recently unable to find node modules. I think NX would end up with a ton of issues when its related to bun not NX

[Jordan-Hall]

Ive taken a look at your project, with nx and bun. This doesn't actually enforce bun runtime and you still relaying on alot of node rather than bun. I've commented on the PR

[ciekawy]

I assume bun was used just for dependency resolution

[Jordan-Hall]

They no point is someone using bun just for node modules. Its a replacement runtime (no need for node), build and modules

[laynef]

Please merge for Bun.js support on NX: #22283

[jaysoo]

The PR to support Bun as a package manager is planned for Nx 19 (in two weeks). #22602

Thanks to @Jordan-Hall for the PR and helping to land this. We'll use this as a starting point for future Bun support (i.e. as a runtime).

[Jordan-Hall]

No problem. I didn't want to maintain a patch or nx bun for any longer :) I think you could just use nx/node rename to nx js-runtime. Default to node and add a option for bun. Especially with it being node supported.

[johngrimsey]

Nice work @Jordan-Hall