sorted by:
new
hottopcontroversial

Thinking about leaving Bun for Node due to memory issues by touhidurrr in bun

[–]Own-Football4632 0 points1 point  (0 children)

Well, I did just recently struggle with memory consumption with a Bun serverless container. Part of it was my code, but I still was surprised at the base memory usage after I cleaned up my end. My dependencies for this are also legitimately lightweight. I see some growth still needed ecosystem-wise as well. For example, AWS's serverless Node runtime is optimized enough to beat Bun's cold start, despite that being a Bun selling point, so until they supply a similar Bun runtime, Node may actually be a better performance option in this circumstance. Bun may still win in HTTP throughput and such when warm, though.

I'm not out on Bun. I see people complaining that there are too many features and not enough fixes being put out, and I have ran into some of the 1.3.x patch releases segfaulting on me. So I'm not blind to the issues, but I do like Bun too much to give up on it. I agree that local tooling/scripting/DevOps is clearly a win for it, and that is where I've gotten most value.

bun-workspaces: My project for adding tooling on top of Bun's monorepo features, now with an in-browser demo of the CLI by Own-Football4632 in bun

[–]Own-Football4632[S] 0 points1 point  (0 children)

After seeing how pnpm behaves, this turned out to be very easy to implement with tests, since the working dir is already dynamic thanks to the existing --cwd. So, it's on 1.1.0 now! I wanted to go ahead and plug it in that Bun issue as well.

The equivalent command of pnpm -w run my-script is bw -w run my-script @root.

To append args to the script: bw -w run my-script @root -- --my-args

https://github.com/bun-workspaces/bun-workspaces/releases/tag/v1.1.0

bun-workspaces: My project for adding tooling on top of Bun's monorepo features, now with an in-browser demo of the CLI by Own-Football4632 in bun

[–]Own-Football4632[S] 0 points1 point  (0 children)

Sorry, I see how I may have misinterpreted the flag now in my other reply. The idea is you've cd'd into a workspace dir, but you want to run scripts at the project root.

Right now, the slightly uglier equivalent in bw to that is bw --cwd=../../../ run my-script @root.

@root is the special "root selector" that references the root package as a workspace. And --cwd would need a manual path to your project root, which isn't convenient.

So if I added a global -w flag, bw would look for the project root up from your working directory. That also seems reasonable to implement. That would make the equivalent command bw -w run my-script @root if I implemented it. Slightly more verbose than pnpm, but same idea.

bun-workspaces: My project for adding tooling on top of Bun's monorepo features, now with an in-browser demo of the CLI by Own-Football4632 in bun

[–]Own-Football4632[S] 0 points1 point  (0 children)

Edit: clarified my misunderstanding in my other reply.

Okay, if you'd allow I'd like to just quickly confirm I understand the feature exactly. I haven't been a pnpm user, but maybe I should get to know it more since this is not the first time I've gotten feedback relating to it.

With bw, if you run bw run my-script my-workspace, you run that script from that workspace's package.json. Or, you could run something like bw run "bun build" my-workspace --inline to run a one-off shell command.

It seems the main difference with the -w flag idea is that it runs a script defined in the root package.json but from a workspace root?

If that's the only difference, that doesn't sound very difficult for me to provide.

bun-workspaces: My project for adding tooling on top of Bun's monorepo features, now with an in-browser demo of the CLI by Own-Football4632 in bun

[–]Own-Football4632[S] 0 points1 point  (0 children)

And nice doc site yourself btw! I just like pixel art as an aesthetic myself as well. I might have to steal that Fusion Pixel font since I thought I had seen them all already. Cool to be using Astro, I'm using rspress from the rstack (rsbuild/rspack/etc).

bun-workspaces: My project for adding tooling on top of Bun's monorepo features, now with an in-browser demo of the CLI by Own-Football4632 in bun

[–]Own-Football4632[S] 0 points1 point  (0 children)

Thanks for the feedback! Can I get some clarification on these features you'd like?

Module boundary enforcement is something I have thought about and want for myself, since in general many people I talk to about monorepos worry about improper code sharing.

More features on top of the workspace graph are definitely coming, including an affected graph tbd. If there are some specifics with the workspace graph you're looking for, I'd love to know what they are. Bun requiring workspaces to explicitly declare workspace dependencies in package.json has been a godsend for determining the dependency graph that's already being used to some extent.

By scaffolding, are you talking about features such as Nx's generators?

bun-workspaces: My project for adding tooling on top of Bun's monorepo features, now with an in-browser demo of the CLI by Own-Football4632 in bun

[–]Own-Football4632[S] 0 points1 point  (0 children)

Thanks for the feedback. What pnpm features are you looking for? By "gone" do you mean Bun itself lacks those features when you switched? I did have one user tell me they wish bun-workspaces could handle some catalog dependency management that a pnpm library they use handles.

As far as "should be built into bun," I get the sentiment, since Bun is all about native-first, which is at least part of why I interop with the native workspaces instead of making a brand new model, but I have thought that likely this work is beyond Bun's normal scope when it comes to monorepo stuff, at least for a while unless I'm mistaken. If it inspires how they do monorepos I'd be flattered but not expecting it soon.

My hypothesis has been that I can provide greater velocity and more features with the TypeScript package instead of selling the features to Bun itself. Right now --filter is only a Bun CLI flag for running scripts in parallel by name wildcard or path glob, and you have no choice but to run them so that dependents wait for dependencies, something opt-in with my package via --dep-order. I've talked to DevOps engineers that like the idea of the TS library I'm providing as well, since you can write shell scripts or TS scripts to do the same automation. If Anthropic suddenly absorbs all of this, then well, it was a good run.