-
(for context - I'm not interested in first class node support)
This seems pretty cool. I particularly like how 'gradual' it seems to be relative to things like Bazel, i.e. you can take some shell scripts and migrate things over. I did have a play and hit an initial problem around project caching I think, which I raised at [0].
One comment, from the paranoid point of view of someone who has built distributed caching build systems before is that your caching is very pessimistic! I understand why you hash outputs by default (as well as inputs), but I think that will massively reduce hit rate a lot of the time when it may not be necessary? I raised [1].
As an aside, I do wish build systems moved beyond the 'file-based' approach to inputs/outputs to something more abstract/extensible. For example, when creating docker images I'd prefer to define an extension that informs the build system of the docker image hash, rather than create marker files on disk (the same is true of initiating rebuilds on environment variable change, which I see moon has some limited support for). It just feels like language agnostic build systems saw the file-based nature of Make and said 'good enough for us' (honorable mention to Shake, which is an exception [2]).
[0] https://github.com/moonrepo/moon/issues/637
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Thank you! We have an example monorepo (https://github.com/moonrepo/examples) but at this time it's only JavaScript. We're working on adding Go to this repo, but we personally don't have enough Python experience to add Python. Always open to contributions!
-
I wonder if it has some overlap with https://skaffold.dev/.
-
buildbuddy
BuildBuddy is an open source Bazel build event viewer, result store, remote cache, and remote build execution platform.
-
We started using https://nuke.build/. Early days so can’t comment too much but it seems good so far.
-
Gonna plug our setup which is Justfiles[1] and turborepo.
Just is a much simpler build runner that calls our turborepo tasks.
We define all of our tasks in one justfile (things like repo setup, syncing env vars, and compiling dependencies) and then link them to turbo processes which cache the result.
Massively reduced our cognitive load working with our monorepo, and is lightning fast.
If we ever want to change it will be simple to remove both, so we're not tied to the ecosystem.
[1]https://github.com/casey/just
-
There is also a Rust implementation of Starlark as a starting point https://github.com/facebookexperimental/starlark-rust
To add to everyone else, please don't use YAML. Starlark is great _precisely_ because it is a readable, well known (nearly Python) language that is limited at the same time (no unbounded for loops, no way to do non-deterministic things like get the current time or `random()`).
-
[2] https://github.com/docker/roadmap/issues/7
-
turbo
Discontinued Build system optimized for JavaScript and TypeScript, written in Rust [Moved to: https://github.com/vercel/turborepo]
Kind of. Poster asked if you can prune only deps and exclude dev deps. That's currently unsupported: https://github.com/vercel/turbo/issues/1100
-
one of the benefits of starlark (unlike python): "Starlark is suitable for use in highly parallel applications. An application may invoke the Starlark interpreter concurrently from many threads, without the possibility of a data race, because shared data structures become immutable due to freezing." from https://github.com/bazelbuild/starlark/blob/master/spec.md - it's not python, you can't do recursion (!) and it's more limited (you can't read a file in bazel, and parse it, you have to make this operation into the graph somehow)
-
