Investigate switching to bun or deno

[kevinvandijk]

As mentioned by @seuros on Discord this would improve the developer experience. Lets see if this is worth doing and if we can still easily stay sync with Roo regardless

[EamonNerbonne]

We had some compat issues on the backend with bun, and neither server nor extension uses bun or deno in prod - and we don't control the prod infrastructure at that level at all. My initial reaction is that it's not worth the infrastructural complexity, especially as long as we're trying not to diverge too far from upstream.

[seuros]

What exactly are the backend quirks you’re referring to? I’ve got the full test suite running fine with Bun in under 12s, unless there’s some untested path or obscure edge case, I’m not seeing the problem.

Let’s be real: by mid-2025, any package still breaking under Bun or Deno is likely unmaintained, deprecated, or just npm-era tech debt.

If Kilocode is anchoring itself to support users who haven’t updated their IDE since Sublime Text 2, you are not building for the edge, you are just curating legacy for people who aren’t even your audience.

Those users aren’t experimenting with AI workflows or pushing Assistant integrations. They’re still Yahooing how to disable Copilot autocomplete.

And if the only reason we’re staying legacy is to keep merges with cline or roocode easy, then Kilocode becomes a feature hoarder and hoarders attract bugs, security debt, and complexity. I respect the intention, but it’s not a sane long-term strategy. Features are good, but each feature needs to stay up to date.

Going full-edge would let us drop a ton of compatibility code, use VSCode’s new APIs, and actually simplify the stack. In 2025, there’s zero justification to redo pre-CI/CD compatibility mindsets , the era when the CTO himself had to test the app on his Pentium 3 to allow an upgrade. Companies that do that, will vanish from existence before Kilo sales team get the time contact them offer them a Company solution.

A modern stack means no polyfills, no hacks, no dragging around dead weight to support three outdated installs. That’s not just better performance, it’s better developer velocity. And more importantly, it frees the team to contribute to specs, not workarounds.

I have a full branch with bun migration if you are interested .

[EamonNerbonne]

@seuros Thanks for putting in the work on the branch—totally see where you're coming from. The speed boost you found is no joke; what command exactly are you using to test all the tests in 12 seconds?

The main hang-up is that our production targets—the VSCode backend, the webview, and Vercel—all run on Node.js. What works perfectly in bun for dev can (and already has!) blown up for us in production (well, technically I think deployment broke, but bad enough). IIRC bun uses javascriptcore and node v8, so I suspect that wherever those diverge, bun is going to find it difficult to behave exactly like node.

IIRC even in our limited internal usage we've had at least 3 issues with bun incompatibility - it's more relaxed about CJS/MJS mixing than Node is; for some reason we had issues with a playwrite test failing to have access to TypeORM metadata, and (obviously, but still annoyingly) bun-native methods don't work in node.

Aside; we've also hit subtle but minor incompatibilities between node versions when it comes to error messages, but that affects our testing, which I sort of would expect would hit us in bun too.

So instead of just a free speedup, we'd also be adding a new mental tax of constantly asking, "will this works-in-bun code break in Node?" It also makes pulling updates from the roo-code upstream (which uses pnpm) and pushing any improvements back a bigger headache.

Never say never, and if we choose to deemphasize roo source-level merge-friendliness things might change. Even then though, I'd prefer a solution that's fast and similar to how prod works to something so deeply different that happens to emulate node quite well.

It's a tradeoff. Do you think bun is much faster in practice than pnpm with turborepo, assuming caches aren't empty?

[seuros]

what command exactly are you using to test all the tests in 12 seconds?

bun run test after ditching turbo using kilo.

Yes , Bun is still faster than pnpm + turborepo, even with warm caches.

Turbo is great for large monorepos with heavy incremental builds. But for most real-world daily dev cycles, running tests, scripts, installs, Bun dominates. It skips the Node overhead, handles workspaces natively, and avoids orchestration layers like turbo. Fewer moving parts = faster iteration = higher velocity.

But this isn’t just about speed: it’s about architecture.

1. Node and Bun can cohabit cleanly.
   Bun can handle testing, linting, and dev workflows. Node can stay in place for prod, CI, and legacy toolchains. No lock-in. No drama.

2. Bun lets us finally dump Jest , which has become the webpack of test runners: slow, bloated, and outdated. Bun’s native runner is zero-config, typescript-native, and orders of magnitude faster.

3. Let’s be real: Node was architecturally flawed.
   Ryan Dahl built Deno for a reason. Module resolution, globals, security, all botched early. Bun doesn’t fix Node, it replaces the mess.

4. VSCode extensions don’t run on Node.
   The webview runs in a Chromium sandbox, meaning it executes in V8, not Node, not Deno, not Bun. So concerns about Bun affecting extension UI behavior are misplaced, they're just browser code running in a sandbox.

5. Vercel has supported Bun natively since September 2023.
   That’s almost 2 years of production support. Even edge functions run on Bun now.

So the only real blocker is upstream merge convenience with roo-code. And that’s fine, but it’s a social decision, not a technical one.

You can close the issue for now. 👍🏼

[EamonNerbonne]

Bun is multiple things. When you use it as a test runner, you're using its runtime, not just its bundler (which is what vercel supports). However, that runtime is AFAIK not supported on vercel serverless functions, to this day. And while indeed node isn't v8 and bun isn't javascriptcore, bun does use javascriptcore wheras node uses v8. And again, we have used bun and did see multiple different sources of incompatibility. Most of which are fixable (not sure about the metadatareflection one), but the real problem is that the whole point of tests is to predict how things will behave in prod and our prod is largely node (and indeed a part is in a chromium webview), and all of that is quite different to the bun runtime, which explains the actual observed incompatibilities, and makes me concerned about using it as a test runner.

But yeah, the merge issue is a major part too. It's not by itself a reason not to do anything, but we do consider the number and kind of changes needed heavily - if your branch mostly adds files rather than altering them, that for instance would reduce merge risk.

[seuros]

While Vercel officially supports Bun as a package manager during the build phase , it does not natively support Bun as a runtime for serverless functions. That true.

However, The OSS community is not going to wait for corporate figure it out. The community has build custom runtimes that enable deploying serverless functions using Bun on Vercel. https://www.npmjs.com/package/@godsreveal/vercel-bun

You are correct that Bun uses JScriptCore (JSC) as its engine, while Node.js uses V8. This difference can lead to small incompatibilities, in areas like error messages, stack traces. but Bun aims to be a drop-in replacement for Node.js and has made significant strides in compatibility. LOL, i start to seem like a Bun's evangelist now.

There is no reason to merge the bun change if nobody from the core team is going to use it. IF some day, it becomes less risky, then the bun work s in fork.