I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for Node (or some defined subset thereof), that inherently means bug/quirk/extension compatibility too (for whatever subset is being targeted).

IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.

This was the battle I was looking forward to Deno taking a hard stance on, but it seems like even they have been forced to make some compromises now. It still seems like they envision people moving (gradually instead of all at once) to more consistent and standardized practices, but it doesn't look like we get to cut off the long tail of compatibility after all

Recent versions of Node.js implement many web APIs. The ecosystem is converging on a mix of web APIs and Node.js APIs. Excluding a few cases (like setTimeout), this won’t be a recurring tradeoff for Bun's runtime APIs (module resolution, however, is complicated).

A problem I had in NodeJS the other day, NodeJS has 3 stream classes: require("stream").ReadableStream

require("stream").Readable require("stream/web").ReadableStream

I was using node-fetch and fastify but I decided to remove node-fetch to just use global.fetch and everything broke.

Turns out node-fetch and fastify uses require("stream").ReadableStream, but global.fetch() uses require("stream/web").ReadableStream (because it is a web standard). Took me a few hours to figure out why it wasn't working, getting some "ReadableStream is not a ReadableStream" error is very fun to troubleshoot

I don't know what approach Bun should take in this regard, but I would like to see NodeJS deprecating non-standards as much as possible so eventually this problem can go away. ECMA should also standardise things required for server-side code more