Launch HN: Moonrepo (YC W23) – Open-source build system
131–140 of 176 posts
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#132Bazel 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…
I think it's hilarious to say bazel focuses on correctness when it doesn't ship with any hermetic toolchains by default. Properly setting up hermetic toolchains is poorly documented and left as an exercise to the reader. I say this as someone who wants to love bazel... I just can't understand why it picks up impure toolchains from the system at all.
Combine that with the fact that C++ toolchains at least make assumptions all over the place about being spewed over `/usr`... I think they just bowed out to practicality at that point.
You're definitely right it should use hermetic toolchains. I'm curious which other Bazel-like build system does that by default?
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#133Bazel 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…
> 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. Thi…
Also a bit disingenuous to describe it as language agnostic if it only really works with non-compiled languages.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#134Bazel 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…
I think it's hilarious to say bazel focuses on correctness when it doesn't ship with any hermetic toolchains by default. Properly setting up hermetic toolchains is poorly documented and left as an exercise to the reader. I say this as someone who wants to love bazel... I just can't understand why it picks up impure toolchains from the system at all.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#135Configuration is code, so the YAML written in your tool is still code, code that developers are consuming and versioning. Making it YAML doesn’t make it not code . Your YAML configuration files are proprietary syntax , it is a proprietary code syntax written in a language (YAML) lacks basic abilities for logic or control flow. In a system of any worthwhile complexity, inevitably custom build logic will have to be exp…
Aside from the classic `country_code: NO`, the other day I ran into issues with scientific notations. Now, guess, which of the following are strings, and which are numbers:
- 1e+10
- 1.e+10
- 1.0e10
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#136Earlier quoted context omitted.
Look at https://moonrepo.dev/docs#supported-languages They only fully support Javascript. The complex stuff, like defines, C++ toolchain, dynamic libs, etc.. is all out of scope.
Wow true. Claiming to be a build system yet being limited to JS... Apparently, the legions of JS developers think the web is the only thing that exists today.
That's very unfair to JS devs. We're well aware that other things exist...
...because we're trying to replace them all with JS.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#137Configuration is code, so the YAML written in your tool is still code, code that developers are consuming and versioning. Making it YAML doesn’t make it not code . Your YAML configuration files are proprietary syntax , it is a proprietary code syntax written in a language (YAML) lacks basic abilities for logic or control flow. In a system of any worthwhile complexity, inevitably custom build logic will have to be exp…
Why? Why YAML? Why? YAML is absolutely terrible! Aside from the classic `country_code: NO`, the other day I ran into issues with scientific notations. Now, guess, which of the following are strings, and which are numbers: - 1e+10 - 1.e+10 - 1.0e10
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#138Earlier quoted context omitted.
Yes! Prune then zip the output folder.
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
I build my packages regularly (not pruned), then I prune with scope "backend". Apparently the pruned directory contains node_modules with empty packages, not sure what reason is for that; I just ignored it. In the resulting directory I then run `pnpm install --prod`. Only the regular dependencies will be installed. I think this is enough for my usecase. I am not sure if prune is supposed to be used for this approach though.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#139Earlier quoted context omitted.
Are you sure you can't have your cake and eat it too? You can have many configuration options, but give each one a sane default.
In my experience (Bazel, sample size of 2 projects), the complexity doesn't come from configuration options that have defaults, but from how well the "mental model" of the build system fits the preconceived notions of how to structure, organize, and depend on code in an existing project. Almost none of the complexity comes from what configuration options I've registered ahead of time. It comes almost entirely from, "…
This runs counter to how most people think of things like Bazel which are tools you should only reach for when the situation has already grown out of control.
Re: Launch HN: Moonrepo (YC W23) – Open-source build system
#140> We wanted our system to be enjoyable to use and easy to understand, but also solve the same problems as existing systems. For example, configuration is in YAML, not a proprietary syntax I'm incredibly skeptical of this. I'm ex-meta and have worked a lot with the enterprise solutions you're talking about and the choice of starlark (originally python) as the build definition language is one of the killer features of…
Based on everyone's feedback about YAML (we didn't expect this much), we'll probably reconsider this!