mileswjohnson

<3

Should give moon a try if you ever have free time :)

moon will only run on affected projects, so you're not building/testing everything. This is done through a combination of hashing + caching.

It's also language agnostic because you can technically run anything through moon, but support may vary. https://moonrepo.dev/docs/faq#can-we-run-other-languages

We'll get there eventually! Adding support for other languages in Rust is a very long process.

At a quick glance, I don't believe there's any overlap.

Yes it can! That's pretty much the only way it works. The `moon run` command will only run if affected by changed files, and `moon ci` will only run affected tasks/projects in CI pipelines.

Thanks will take a look at.

Gotcha. While moon doesn't solve this directly, you do have a few options here:

- Use git submodules. Have the node repo have a submodule on the app repo.

- Publish the shared code to a private registry (like github's package registry), and pull it in as an npm package.

Yeah, we kind of regret mentioning Bazel in the original post, but we can't change it now.

Based on everyone's feedback about YAML (we didn't expect this much), we'll probably reconsider this!

Thanks for the feedback and prototyping with it immediately! Always appreciated to get hands on feedback.

We have a long ways to go, but our end goal for moonbase is basically buildbuddy, but for non-bazel users. Right now moonbase requires moon, but we're looking to decouple it.

If you end up using moon, and there's anything abrasive/convoluted, let us know! We're always looking for ways to streamline.

> Does it enforce hermecity or deterministic builds or give me tools to accomplish it?

I wouldn't say moon is hermetic, nor are we trying to be. We don't use the sandbox approach for tasks, and run against the original files. For the languages we support, this works best.

As for deterministic, we try to be. We have a "toolchain" where we download languages/tools in the background, and run tasks using these tools. This ensures, at minimum, that the same version/variant of a tool is used across machines.

> In the same vein as those questions how does caching work?

It's content based. We also hash other kinds of inputs depending on the language that is running.

> If the configuration language is YAML how am I expected to implement new behavior? (and other questions)

Our focus right now is on non-compiled languages, primarily web languages, where custom behavior (like Starlark) is not necessary. In the future, this may change.

Can you speak to what kind of "functionality" you need a language for? Are you referring to Starlark-like files?

Can you talk a bit more about what kind of code is being copied?

Thanks for the feedback. Too much configuration is something we keep thinking about, and are working to streamline. It's a bit involved since we support multiple languages.

We agree. We weren't happy with all of the current solutions, at least in the JavaScript space.

In regards to build graph invalidation, we attempt to hash pieces at the granular level. This includes per file content hashing, and for dependencies (those in `package.json`), we parse the lockfile and extract the resolved version/integrity hashes. We can probably improve this further, but this has been working great so far.

As for phantom dependencies, this isn't something moon solves directly. We encourage users to use pnpm or yarn 3, where these phantom problems are less likely. We don't believe moon should solve this, and instead, the package managers should.

If you have any other questions or concerns, would love to hear them.

I don't disagree here. At the moment, moon leans closer to a task runner, with hashing, incremental caching, and other features tacked on. All of our currently supported languages are not compile based languages, and run with pre-built binaries.

Once we starts supporting more languages, especially compile based ones (probably Rust first), our decision around YAML will probably change. Off the top of my head, a non-YAML format would probably be used as a secondary format, kind of like how a Dockerfile works.

Thank you. This is how we feel as well.

A lot of our decisions were based on our past experience with Bazel. We both have worked at companies that tried to use Bazel and failed miserably. There's stuff we like about Bazel (and copied in some capacity, like file groups), and definitely parts we hate about Bazel.

Bazel doesn't work well for every language, but for those languages that it does, it definitely makes sense to use Bazel. For those languages that work better with something more lightweight, that's where moon comes in. I'm assuming you work at Google, so you're experience around Bazel is probably much better than those that don't work at Google.

I appreciate all the feedback and comments though, very much appreciated.

We haven't built the on-prem solution yet, but we're leaning towards using Helm charts + Kubernetes. At minimum, it will all be Dockerfile based.

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.

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.

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.

I'm not very familiar with Buck. But I'm assuming it works the same way as Bazel's Starlark?

I can see the benefits of "generating code" within the BUILD file, but honestly, we haven't required it yet, and have been able to do most things with explicit configuration. Our token syntax helps with some dynamic aspects of this.

Maybe in the future we'll revisit this.

Yeah that's fair feedback. At this time, we consider ourselves more of a Bazel-lite than an actual Bazel replacement. Once we support more languages and features, this may change in the future.

We chose YAML for a few reasons. The first being that we wanted a format that is basically universally supported everywhere. This filtered down to JSON, TOML, and YAML. JSON is an awful configuration format, so that was a no go. TOML is pretty great, but is also not very ubiquitous. That left us with YAML.

The second reason is we wanted something language agnostic and not proprietary. It also helps that many other tools, like GitHub actions, are written in YAML.

And lastly, we wanted a format that developers are familiar with, and won't need to spend time learning. Requiring developers to understand a special syntax simply to define a task to run is something we want to avoid.

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.