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

71–80 of 176 posts

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

#71

Post by lhorie »

mileswjohnson wrote: post #51
lhorie wrote: 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…

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 f…

I guess I'll echo some of the other comments re: extensibility. For us, Bazel's Starlark language is useful because it allows us to integrate w/ non-JS things like protobuf schema definition files. I suspect most companies are going to have hybrid stacks instead of Node.js-only ones. FWIW, Bazel vs Buck have some history wrt adoption wars, and Bazel largely pulled ahead due to a better ability to flourish an ecosystem (hell, the entire JS ecosystem around it is done via the extensibility system). It very much reminds me of how Typescript won against Flow.

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

#72

Post by bovermyer »

mileswjohnson wrote: post #56
bovermyer wrote: post #48

Would this be overkill for a personal project that is currently two repos, but I'm having to copy-paste code from one to the other whenever I make a change to a particular section?

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

The main repository is a single page app that's mostly Typescript compiled via Svelte down to a JavaScript bundle.

Most of that repository is a series of modules in their own directories (e.g., "src/modules/character").

The second repository is a Node.js API. The majority of its functionality comes from one of the modules from the first repository that I copy in its entirety to the other repository whenever I change it.

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

#73

Post by theamk »

haberman wrote: post #57

> Tasks are defined and run as if you were running them in the terminal; no more abstractions like BUILD files. But abstractions are a good thing! They let you separate a system into layers, so that things programmed at a higher layer don't need to know all the details of the lower layers. It's the way we separate interface from implementation. Let me give an example from Bazel. Suppose you are compiling some C or C+…

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.

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

#74

Post by mileswjohnson »

aidanhs wrote: post #53

(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 b…

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

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

#75

Post by angio »

quickthrower2 wrote: post #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.

I'm a big fan of using nix to achieve that. https://determinate.systems/posts/nix-github-actions

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

#76

Post by [deleted] »

palmdeezy wrote: post #47
lhorie wrote: 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…

[deleted]

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

#77

Post by rfoo »

mileswjohnson wrote: post #44
Denzel wrote: post #36

Earlier quoted context omitted.

I'm not trying to be overly critical here, in fact, I want to share the type of empathetic feedback I'd hope to receive as a founder. Have you actually talked to Blaze/Bazel users to understand what frustrations (if any) they have with their current build system? Have these users asked for a Bazel-lite? If so, and you still want to position yourself as Bazel-lite, then you should include some of their direct feedback…

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…

I see that you are targetting the Web ecosystem. IMO using Bazel in this case was pretty tough, and may still be. The way Bazel does things may not make sense for 95% JS projects (and 99.9% FOSS projects), so I wonder whether it's better to simply drop the mention of Bazel. Just don't compare to Bazel.

Better “monorepo-ish” (whatever that means in the frontend world) tools are still valuable, but as GP said, it's pretty crowded here.

I don't know if you have talked with people working on C++ or Java projects (I see that these are not among your supported languages), but if you do, you get to see why people are talking about Bazel.

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

#78

Post by howinteresting »

Denzel wrote: post #36
mileswjohnson wrote: post #17

Earlier quoted context omitted.

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.

I'm not trying to be overly critical here, in fact, I want to share the type of empathetic feedback I'd hope to receive as a founder. Have you actually talked to Blaze/Bazel users to understand what frustrations (if any) they have with their current build system? Have these users asked for a Bazel-lite? If so, and you still want to position yourself as Bazel-lite, then you should include some of their direct feedback…

I think it's more illuminating to talk to people who tried to use Bazel and failed, often wasting months in the process.

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

#79

Post by duped »

mileswjohnson wrote: post #58
duped wrote: 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.

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

Turing completeness. No, I'm referring to using Python (waf, conan, etc), Javascript (nodejs scripts, esbuild, etc), and other "real" programming languages.

It's incredibly frustrating to have to configure a build with something as shitty as YAML. There's a tangible amount of money I have wasted in organizations on it.

A build is not actually a static configuration of another system. It's a program and deserves everything we need from programming languages.

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

#80

Post by jcalder »

> 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 the systems.

People want to create macros, target generators, etc. It's a common use case for a lot of engineers and IMO is a pretty killer feature.

Being able to say "This is an X86 Python Binary", "This is an M1 python binary" and then bundle those into "this is how you build either of those binaries based on inputs" without ever touching the internals or anything other than (more or less) a blob of python is why those tools scale organizationally.

It allows the teams that need to do weird stuff to unblock themselves without drowning the tools org. Sure, it has draw backs. Super deep macro layers are kinda a crime against humanity and debugging/evolving them can be quite expensive, but I think that's just the cost of software.

If that logic isn't in the build definitions it'll expand into a meta layer that generates configuration (I've seen giant "Translate this definition into 30 configs to run stuff" systems time and time again).

I may just be super biased from past mistakes and wins, but I think what you're doing is just moving the complexity out of your tool into neighboring tools and selling it as a win isn't really true, it's shuffling complexity around not removing it.

Post reply on HN