Parallel and sequential, especially at the command level, are really the wrong abstractions for running scripts. If you have multiple packages, each with builds, there's a high chance you have dependencies and multiple packages depending on common ones. What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need…
If only we could make something like that But now we would need each script to independently do their own caching, which isn’t all bad. At least you have more cross runner compatibility and resilience
Bun v1.3.9
31–40 of 54 posts
Re: Bun v1.3.9
#32Parallel and sequential, especially at the command level, are really the wrong abstractions for running scripts. If you have multiple packages, each with builds, there's a high chance you have dependencies and multiple packages depending on common ones. What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need…
> What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need to be run because their inputs didn't change. DAG + content-addressing, final binary being the target and everything resolved from there. We could have some beautiful build system that just works and is fast, but seems it never magically appears by it…
Re: Bun v1.3.9
#33Earlier quoted context omitted.
> What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need to be run because their inputs didn't change. DAG + content-addressing, final binary being the target and everything resolved from there. We could have some beautiful build system that just works and is fast, but seems it never magically appears by it…
Google's build system Bazel is what you describe.
Re: Bun v1.3.9
#34Parallel and sequential, especially at the command level, are really the wrong abstractions for running scripts. If you have multiple packages, each with builds, there's a high chance you have dependencies and multiple packages depending on common ones. What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need…
> What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need to be run because their inputs didn't change. DAG + content-addressing, final binary being the target and everything resolved from there. We could have some beautiful build system that just works and is fast, but seems it never magically appears by it…
Re: Bun v1.3.9
#35Parallel and sequential, especially at the command level, are really the wrong abstractions for running scripts. If you have multiple packages, each with builds, there's a high chance you have dependencies and multiple packages depending on common ones. What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need…
Re: Bun v1.3.9
#36Is it more common in English to use there terms Parallel and Sequential or Parallel and Series ? Made a React Library to generate video as code and named two components I was wondering if those were two best terms two use...
Using the singular "Sequence" might also be appropriate for a component name, as the component represents the collection entity, rather than referring directly to the things within the collection itself (which I presume are either a prop or the children of the component).
Re: Bun v1.3.9
#37Earlier quoted context omitted.
Google's build system Bazel is what you describe.
I should really give it another look, I usually ended up not adopting it for projects because of the boilerplate and high setup overheard, but those are both things that ai agents can usually be trusted with. Maybe the calculus has changed.
Re: Bun v1.3.9
#38Re: Bun v1.3.9
#39Earlier quoted context omitted.
I should really give it another look, I usually ended up not adopting it for projects because of the boilerplate and high setup overheard, but those are both things that ai agents can usually be trusted with. Maybe the calculus has changed.
Yeah Bazel is a PITA to do yourself. I haven't tried but I'm confident Claude et al. would handle it just fine. By similar logic I recently adopted NixOS for a lot of my servers; Claude is perfectly happy to slog through the pain of Nix configs for me.
Gazelle, the BUILD file generator for Go, now supports plugins and several other languages have Gazelle plugins.
I’ve used AI to generate BUILD file generators before, though. I had good luck getting it to write a script that would analyze a Java project with circular dependencies and aggregate the cycle participants into a single target.
Re: Bun v1.3.9
#40Earlier quoted context omitted.
Google's build system Bazel is what you describe.
I should really give it another look, I usually ended up not adopting it for projects because of the boilerplate and high setup overheard, but those are both things that ai agents can usually be trusted with. Maybe the calculus has changed.
I don’t like generative AI for rote tasks like this, but I’ve had good luck using generative AI to write deterministic code generators that I can commit to a project and reuse.