Live data from Hacker News

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

news.ycombinator.com

61–70 of 176 posts

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

#62
post #21

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…

Bazel as a taskrunner/build system is to most monorepos as a Pile Driver [1] is to a floorboard nail. It will do everything but it's massive overkill. We are agreed that Nx doesn't measure up, but I wouldn't compare it to Bazel.

[1] https://en.wikipedia.org/wiki/Pile_driver

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

#63
post #59
post #39

IMHO, if you're targeting the Javascript ecosystem, this area is already fairly crowded, with Turborepo, Nx and various open source tools providing various degrees of functionality (Bazel, Pants, Lerna, etc) already competing in the space. I'm a tech lead for the web monorepo at Uber. We talked to the Turborepo guy a few years ago, and he admitted that he wasn't sure if it could handle our scale in terms of all the b…

Nx is hot garbage imo. Buggy, overly verbose, inflexible, poorly documented, and I'm dubious about their peer review process. If I don't need build caching I'm not using any tool but PNPM and its workspace toolset - that's literally all most people need for a monorepo. I've looked into Turborepo, and its simplicity versus Nx is a strength. However, it's not the taskrunner that I want. I now work in a monorepo where b…

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

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

#64
post #2

What's the motivation for using YAML instead of Starlark (Bazel, Buck) or something closer to Python (Pants, please.build)? Seems as though much of the other monorepo tools have (kinda) standardized on this. As I understand it, the primary reason these build systems leverage these Python-variants is so that the build rules, toolchains, constraints, and build definitions can all be written in the same language (since…

I much prefer YAML rather than having to write more code for a build system.

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

#65
post #61

How do you compare with BuildBuddy? BuildBuddy embraces Bazel, but makes it easier to setup and operate Bazel when you don't have Google infrastructure. - https://www.buildbuddy.io/ - https://github.com/buildbuddy-io/buildbuddy

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.

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

#66
post #43

I'm supremely disappointed to see another service using YAML to configure task running. I do in fact need a real programming language to do this, and copying others in this vein is inheriting mistakes and not picking a battle-tested solution. What you will find is the vast majority of your configurations will invoke a make.sh script that does everything that you want to support in your system.

Conversely, if moon required code instead of config, I wouldn't give it a second look. Ecosystem needs vary greatly.

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

#67
post #39

IMHO, if you're targeting the Javascript ecosystem, this area is already fairly crowded, with Turborepo, Nx and various open source tools providing various degrees of functionality (Bazel, Pants, Lerna, etc) already competing in the space. I'm a tech lead for the web monorepo at Uber. We talked to the Turborepo guy a few years ago, and he admitted that he wasn't sure if it could handle our scale in terms of all the b…

Turborepo author here… We do not invalidate the whole graph anymore for a lockfile change. We now have a sophisticated parser that can calculate if a change within the lockfile should actually alter the hash of a given target. In addition to higher cache hit rates, this is what powers our `turbo prune` command which allows teams to create slices of their monorepo for a target and its dependencies…useful for those bui…

Can Prune be used to build a bundle (as in a zip) for, say AWS Lambda, which includes only the dependencies (and not dev dependencies)? I've played around with pnpm's deploy but it felt a bit lackluster. Especially talking about situation where one has a backend package and some shared package. The bundle should contain all dependencies (but not dev dependencies) of the backend package and shared package and of course the built shared package should also be include in the bundle's node_modules.

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

#68
Apologies if this sounds reductive but can I think of it as an open source CircleCI?

The thing that annoys me most about CircleCI, TravisCI, Github Actions and Appveyor is that there is no simple way to run the same thing locally to debug or test workflows without creating either git history mess or temporary hacks like taking off branch restrictions in the yaml.

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

#69
post #67

Earlier quoted context omitted.

Turborepo author here… We do not invalidate the whole graph anymore for a lockfile change. We now have a sophisticated parser that can calculate if a change within the lockfile should actually alter the hash of a given target. In addition to higher cache hit rates, this is what powers our `turbo prune` command which allows teams to create slices of their monorepo for a target and its dependencies…useful for those bui…

Can Prune be used to build a bundle (as in a zip) for, say AWS Lambda, which includes only the dependencies (and not dev dependencies)? I've played around with pnpm's deploy but it felt a bit lackluster. Especially talking about situation where one has a backend package and some shared package. The bundle should contain all dependencies (but not dev dependencies) of the backend package and shared package and of cours…

Yes! Prune then zip the output folder.

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

#70

You're building something like buck/blaze and replacing starlark with YAML ? I want a full programming language when defining complex rules. Build systems do a lot more than execute commands. You lost me there. Buck/Blaze aren't perfect but configuration was never an issue. Moon like it is currently is a glorified task runner.

We started using https://nuke.build/. Early days so can’t comment too much but it seems good so far.
Post reply on HN