Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Moonrepo (YC W23) – Open-source build system

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 176 posts

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#21

Post by jpgvm »

Bazel has a heavy focus on correctness (pretty much to the exclusion of everything else). Where does Moon fall on the correctness gradient? Does it enforce hermecity or deterministic builds or give me tools to accomplish it?

In the same vein as those questions how does caching work? Is it content based like Bazel or mtime like Nx et al? If there is no sandboxing does it do input tracking or is there manual "cache key" shenanigans?

If the configuration language is YAML how am I expected to implement new behavior? Is that in Rust? Is there a plugin architecture? Do I need to rebuild the tool itself and redistribute it to my build machines and developers? The main appeal of Starlark/Python in build systems is ability to create macros or in many cases define entirely new rulesets to support new tools and languages without needing to modify the complex and performance sensitive core.

Sorry for the skeptisicm but build systems are very complex beasts and new entrants like Nx don't measure up to tools like Bazel very well.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#22

Post by pdeva1 »

one of the reasons Bazel needs BUILD files with explicit inputs /outputs defined per file is to do fine grained incremental builds and test runs. so if i change say foo.c, i only need to recompile foo.obj and run ‘foo-tests’. Moon seems to take globs as input. Thus modifying even a single file inside ‘src’ dir will trigger rebuild/retest of the entire ‘project’

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#23

Post by mileswjohnson »

bunged wrote: post #19
mileswjohnson wrote: post #13

Earlier quoted context omitted.

So moon wouldn't replace your actual CI pipelines. It would be a tool that runs _in your pipeline_ to effectively run tasks as fast as possible. For example, in CI, tasks are only ran if they are affected by files changed in the pull request. No more running everything unnecessarily. We also support remote caching of artifacts, which helps to speed up CI even further, by avoiding long build times.

Interesting, so does it keep all the intermediates from previous builds and then does an incremental build on top of this? Like doing a local dev build but in the cloud?

Yeah at a high-level, that's how it works. However, the incremental caching part does require remote caching of artifacts, so that they can be shared across CI jobs/runs.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#24

Post by QuiiBz »

mileswjohnson wrote: post #10
QuiiBz wrote: post #3

Congrats on the launch! I've been following Moon since a few months, seems like an interesting project. Could you explain why any existing project using Turborepo/Nx should switch to Moonrepo? What are the advantages and disadvantages? The support for multiple languages seems like a big advantage.

I can speak to both of these. I'll start with Turborepo. Turbo is primarily a task runner for `package.json` scripts with some caching... and that's basically it. If that's all you need, then great, but if you're looking for more functionality, that's where moon comes in. moon is more than just a task runner, we're aiming to be a repository management tool as a whole. This includes project/code ownership, direct CI s…

Thanks for your detailed answer.

> release workflows

Looking forward for this, especially if that also means auto-publishing of NPM packages, Rust crates, etc.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#26

Post by bunged »

mileswjohnson wrote: post #23
bunged wrote: post #19

Earlier quoted context omitted.

Interesting, so does it keep all the intermediates from previous builds and then does an incremental build on top of this? Like doing a local dev build but in the cloud?

Yeah at a high-level, that's how it works. However, the incremental caching part does require remote caching of artifacts, so that they can be shared across CI jobs/runs.

Thanks for explaining, that does sound compelling, and useful that it can be slotted into an existing system.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#27

Post by mileswjohnson »

QuiiBz wrote: post #24
mileswjohnson wrote: post #10

Earlier quoted context omitted.

I can speak to both of these. I'll start with Turborepo. Turbo is primarily a task runner for `package.json` scripts with some caching... and that's basically it. If that's all you need, then great, but if you're looking for more functionality, that's where moon comes in. moon is more than just a task runner, we're aiming to be a repository management tool as a whole. This includes project/code ownership, direct CI s…

Thanks for your detailed answer. > release workflows Looking forward for this, especially if that also means auto-publishing of NPM packages, Rust crates, etc.

Yup exactly that! We want a single to to handle version bumping, changelog generation, publishing to a registry, etc, for _all_ languages that we support.

Re: Launch HN: Moonrepo (YC W23) – Open-source build system

#30

Post by mileswjohnson »

pdeva1 wrote: post #22

one of the reasons Bazel needs BUILD files with explicit inputs /outputs defined per file is to do fine grained incremental builds and test runs. so if i change say foo.c, i only need to recompile foo.obj and run ‘foo-tests’. Moon seems to take globs as input. Thus modifying even a single file inside ‘src’ dir will trigger rebuild/retest of the entire ‘project’

Our configuration is using globs but under the hood we content hash all the files that match the glob, and only run/cache if the aggregated hash has changed.

For the languages we currently support, this is more than enough. Once we dive deeper into compiled languages (probably starting with Rust), we'll look into more granular reactivity and possible use something like sccache.

Post reply on HN