Zed errors with node-compatible runtimes such as bun

[nakamorichi]

Summary

Zed assumes Node.js runtime and raises errors when running on Node.js-compatible runtimes, such as bun.

Description

Steps to reproduce:

1. // set bun instead of node "node": { "path": "/opt/homebrew/bin/bun", "npm_path": "/opt/homebrew/bin/bun" },
2. open any project that triggers language servers

Expected Behavior: Zed should work with node-compatible runtimes similarly as e.g. vscode does. Actual Behavior: Zed checks for node-compatible runtime and fails if version doesn't match

error examples:

Language server error: json-language-server

node at /opt/homebrew/bin/bun is too old. want: 20.0.0, got: 1.2.15
-- stderr--

Language server error: biome

node at /opt/homebrew/bin/bun is too old. want: 20.0.0, got: 1.2.15
-- stderr--

Zed Version and System Specs

Zed 0.188.6 – /Applications/Zed.app

[d1y]

Zed now only supports node by hard coding. You have to change the code yourself to switch to bun, and I don't think bun is ready (not 100% compatible with node)

[nakamorichi]

I've been using vscode with bun - actually just for experiment went as far as linking nodejs executable to bun - so I disagree about bun not being ready. Could you give an example of logic in Zed that would fail with latest version of bun, i.e. dependency on Node API not supported by bun? Without concrete example, it doesn't quite sound reasonable to hard-code such requirements.

Regarding API compatibility: https://bun.sh/docs/runtime/nodejs-apis

[notpeter]

Hi @nakamorichi, @d1y has referenced the correct code your bumping up against:

https://github.com/zed-industries/zed/blob/52770cd3ada1d5db86b9050fdd5c2f1d4b0db412/crates/node_runtime/src/node_runtime.rs#L497-L504

We enforce a specific version of node because many tools are untested/broken with old/unsupported node versions. Since Node v18 is EOL, we currently require Node 20 (EOL 2026-04-30). We want this check for node/npm as it reduces our support burden.

I expect there are some compatibility issues (e.g. NODE_EXTRA_CA_CERTS, etc) but a first step would likely be to make it so that if the node path setting ends with bun that we skip the version check. Happy to review PRs.

[versecafe]

It's a decent bit more than the min version stuff, I'm working on a PR to change from node_runtime to js_runtime to allow node bun and deno as replacements now that everyone is getting much more compatible

[nakamorichi]

I implemented experimental Bun support. I'm not experienced with Rust or Zed codebase, so thorough code review is welcome: https://github.com/zed-industries/zed/pull/33165

Getting Bun play nicely with all the Zed logic depending on Node APIs was tricky, but I believe I managed to get it at least somehow work.

[venatiodecorus]

I saw the PR was closed but this issue is still open. Not trying to stir anything up again, but since this issue is still open is it safe to assume this will be added eventually?

[versecafe]

@nakamorichi on the original issue technically a super minimal change would be to check bin -e "consoe.log(process.versions.node)" rather than bin -v to allow "node compatible" runtimes to report the version they're compatible with

[bitaccesscomau]

Node is absolutely torching my battery (MBA M3), to the point I'm running a remote development server. Super keen for bun, and it's very surprising to see that PR closed given Zed's history for pursuing performance. Bun 1.3 was just released further improving interoperability so hopefully we see this re-kindled.

[Necrelox]

Personally, I switched to Zed last week, but I had to switch back because Bun isn't supported 🥲

[versecafe]

Personally, I switched to Zed last week, but I had to switch back because Bun isn't supported 🥲

While it is a bit of a bummer to not have bun supported as a node alternative bun:test runnables support was merged in (not sure if it's in stable yet but should be in preview)

[Necrelox]

@versecafe Yes, I tested it and it works great! I'll wait for Bun's support for the rest (like DEBUG).

[amtoaer]

I think the main issue is that Bun primarily offers runtime API compatibility but falls short on CLI compatibility. Because of that, simply pointing the node and npm binary paths to bun can't guarantee normal operation for most projects.

[versecafe]

@amtoaer while it's true you can't perfectly drop the CLIs in with each other I don't think making a simple impl JSRuntime would be too difficult and really JSRuntime and JSPackageManager should be different, if you use pnpm or bun or deno as a package manager even if you use node to run everything the shared caches for dependencies are a major win to the node_modules pit eating up your storage

[amtoaer]

You are right; but, after a quick look at the code, I found two main issues:

1. Package Management: The NodeRuntime currently exposes run_npm_subcommand directly. To support Bun, we must abstract this into methods like add_package, query_package, and run_script. If third-party plugins use the old method, this will be a breaking change.
2. Runtime Execution: To make sure we use Bun, we need an extra --bun argument. We currently only pass the binary path and can't set these global arguments.

Overall, implementing this change is not that straightforward and likely needs official confirmation from the Zed team before we can move forward.

[HeavySnowJakarta]

for me, when developing with bun and ts, running

bun add -d @types/bun

the language server features (like bun api hints) will work for both vscode and zed