3 ms·
It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing. I'm all for it, and lots of Bun APIs are purely
by chearon 2y ago
It probably looks very wrong to people who still think lots of "modularity" and small packages is a good thing.
I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better?
I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?
- pfg_ 2y agoNode does have the same thing, and you can access it with `--expose-internals` from `const { getStringWidth } = require("internal/util/inspect");`. They don't expose it for some reason.
- 8n4vidtmkvmk 2y agoI'm also still using webpack. Not sure why the community abandoned it. Haven't had any issues. Everything seems to use babel under the hood anyway and they all have their little wrappers over top.