At first, when I saw Bun’s benchmarks, I was amazed. HTTP servers ranking at the top of framework performance lists (like Elysia) were very appealing. Installing npm packages much faster? I would easily trade pnpm for it.
When I read the article Bun hype. How we learned nothing from Yarn here in Dev.to, I was a bit outraged. But today, I tend to agree with it.
As I mentioned in this tweet, I ended up getting somewhat frustrated with how many packages unrelated to the runtime—such as libraries for Amazon S3 and SQLite—were included.
From my experience, I felt that there was a lack of investment in developer experience. Aside from the issues I had with Node/TypeScript eight years ago, the following things had never happened to me while using Node in VS Code—at least until now, in version 1.21.
(A little spoiler here: I ended up using Bun and Node together in the end. Check out the last section to see how I defined this.)
bun --inspect did not respect breakpoints unless there was a port listener or some function "hanging" in the runtime. --inspect-brk and --inspect-wait didn’t work either.
The launch.json file described in the official Bun VS Code extension did work, especially when changing the Bun location to node_modules/.bin/bun. However, this caused serious conflicts when using Volta.sh.
The debugger’s behavior fluctuated intermittently between launch.json and “Run file,” particularly when switching between Remote/Tunnel and local development.
The Web Debugger also had issues, especially failing to respect promise waits when stepping through await lines. It would get completely lost.
Even with sourcemaps, transpiled JavaScript code did not correctly map to the TS files in the same monorepo.
Open ports were also left hanging, so I had to create a task in tasks.json to use as a postDebugTask in launch.json to kill processes with open ports.
{"version":"2.0.0","tasks":[{"label":"kill port","type":"shell","command":"lsof -ti:3000 | xargs kill -9","problemMatcher":[]}]}
Bun's test runner seems excellent, but it is still not integrated with VS Code's Test Explorer like Jest and other runners.
Since it doesn’t appear in the Test Explorer, it’s difficult to visualize and run only the tests that failed in the last run within VS Code.
It does have the --filter option in the CLI, but you would have to manually fetch the failed tests from the last run and specify them manually. Alternatively, you would have to do the same manually with .skip().
Besides that, debugging with the test runner doesn’t seem to be an option, especially given the already poor debugging experience.
Additionally, the test runner has some bizarre assertion errors. I have two packages in a monorepo that reference a third package in their package.json. Even though they are on the same version, the test runner treats this package as if it were different versions. A simple class instance assertion (instanceof) behaves as if the same class had different constructors, causing the assertion to fail.