Support for Deno and Bun

[JonasBa]

Problem Statement

We currently do not support Deno or Bun runtimes, given the rising popularity and community requests, this is something we want to eventually support.

Rough items required to make this work

• See how deno and bun expose native modules
• Modify profiling to detect deno or bun runtime and require the right binaries
• Determine packaging strategy - can we use a single package, what do we do with prebuilt binaries?

Solution Brainstorm

N/A

[timfish]

Deno only supports native add-ons via a Rust re-implementation of Node-API and I don't think there's any plan to support older NAN based native modules.

Their DevTools implementation does not yet support profiling cpu and memory but they do have some basic profiling docs.

[JonasBa]

@timfish I want to move away from NaN anyways, I just used it at the time because it seemed more convenient. This could be a great prompt to remove it.

Thanks for sharing the profiling doc link, I'll see what's possible. It a minimum, getting rid of NAN sounds like a good precursor

[timfish]

It's nice to only build one binary per platform/arch but my understanding was that Node-API doesn't expose the required API points to be able to use it profiling.

[Jarred-Sumner]

Speaking for Bun, we similarly implement Node-API and do not support NAN.

I lack some context on what Sentry’s profiler does (I used Sentry previously in dozens of projects for bug tracking though). JavaScriptCore has a builtin sampling profiler and we currently expose a very limited part of that to JS, via a profile function - https://github.com/oven-sh/bun/blob/767fdfbb97704405cb6442fab243c0896d82819f/packages/bun-types/jsc.d.ts#L50

We’d definitely be open to exposing more though. JSC’s sampling profiler is more low level than profilers most JS developers are used to. It references bytecode instead of source code typically and it usually has a way to tell you which JIT tier the code compiled to. Safari’s devtools wraps it and makes it higher level. But the sampling profiler is pretty efficient and could possibly be used for continuous profiling I think?

The other weird thing about Bun’s environment is all files are transpiled. Error.prototype.stack isn’t currently modified which means that it points to the transpiled output’s source stack instead of the input. We internally keep sourcemaps in-memory of every file though and Error.captureStackTrace is implemented to support getting the source mapped source.

Bun supports the ”bun” package.json export condition which hopefully is enough to target bun-specific code if necessary

[JonasBa]

@Jarred-Sumner thanks for the context and pointers to bun's source code.

The sentry profiler currently just calls into the underlying v8::CpuProfiler, we dont sample the stacks ourselves. I'll look into JSC sampling profiler - sounds like the first step to get Deno and Bun working is to get rid of NAN, so I'll start there. I'll keep updating the issue as we go along.

[JonasBa]

First part of this was done - profiling now uses napi. I sadly don't have much time to spend on this in the following weeks but next up is figuring out what happens in Deno and how we could use the JSC profiler. Will likely check Deno support first as it should be less of an undertaking assuming they use the v8 profiler already.

[Jonatthu]

@JonasBa hello! How's this going?

[JonasBa]

@Jonatthu No progress on this. There just hasn't been much interest from the community which would justify this tbh. Are you interested in using this in deno?

[Jonatthu]

@JonasBa I am using bun currently with sentry.

[JacobReynolds]

Using it with Bun in production as well, loving everything except not being able to use the profiler.

[JacobReynolds]

It looks like the latest release of bun adds increased support for nan