[delayed]

What were the most significant missing bits?

The worst thing is issues without any visibility.

The other day I was toying with the MCP server (https://github.com/modelcontextprotocol/typescript-sdk). I default to bun these days and the http based server simply did not register in claude or any other client. No error logs, nothing.

After fiddling with my code I simply tried node and it just worked.

It definitely works in bun just fine. I have a production built mcp server with auth running under bun.

Now if you convert the request / response types to native bun server, it can be finicky.

But it works fine using express under bun with the official protocol implementation for typescript.

Actually writing a book about this too and will be using bun for it https://leanpub.com/creatingmcpserverswithoauth

Not sure about the specific underlying apis, but as of my last attempt, Bun still doesn't support PDF.js (pdfjs-dist), ssh2, or playwright.

localAddress is unsupported on sockets, meaning you can not specify an outgoing interface, which is useful if you have multiple network cards.

is there a way to wrap their s3 client for use in HonoJS/CF workers?

No. It's implemented in native code (Zig) inside bun itself and just exposed to developers as a JavaScript API.

Source code: https://github.com/oven-sh/bun/tree/6ebad50543bf2c4107d4b4c2...

10/10 Loving it (and how fast it is!) - its just not the use-case that fits my needs.

I want maximum ability to "move" my projects among services/vendors/providers

Proividing built APIs to not rely on NPM is one of the most interesting aspects of Bun IMO.

Can someone explain the advantage of this?

If I want S3 access, I can just use NPM

If I don't want S3 access, I don't want it integrated into my runtime

Would you rather use an officially maintained solution or some random package by a random author who might abandon the project (or worse)?

The S3 packages on NPM are maintained by AWS

Indeed but I was arguing about a general point.

I'd be surprised if any of your Node projects had less than 100 total deps of which a large number will be maintained by a single person.

See Express for example. 66 total deps with 26 deps relying on a single maintainer.

https://npmgraph.js.org/?q=express

But even in the case of the official aws-sdk they recently deprecated v2. I now need to update all my not-so-old Node projects to work with the newer version. Probably wouldn't have happened if I had used Bun's S3 client.

So let's put every package under the sun into the client?

This approach does not scale. We should make NPM better.

How do you make NPM better?

BTW I'm not saying we should kill NPM. What I'm saying is we should reduce our dependance on random packages.

Bun doesn't need to add everything into the core engine. Eg: when using .NET you still add plenty of official Microsoft dependencies from Nuget.

- NPM could migrate to reproducible builds of artefacts

- Trust could be opt-in by default

- Dependency installation could be made fully reproducible

I came here to say the same thing.

Rather ship oven/bun through docker and have a 90mb container vs using node.