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

141–150 of 176 posts

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

#141

Post by jpgvm »

eric_khun wrote: post #115

We've started using Rush [1] at Buffer. Teams have been slowly migrating, and it has been great so far. We had (too many) repos with their own workflow and way too many different ways to build services, which has been annoying to maintain. I know teams use Rush at scale: Tiktok has ~450 projects, and Microsoft said they have ~700 projects. To deploy the services locally, we use Tilt[2] (K8s for local). We want to be…

This is where Bazel + rules_js ecosystem shines. First of all it lazily fetches dependencies which means if you are only building 1 out of X projects you are only getting your projects dependencies from npm, then it's only providing just those dependencies to the sandbox when you are doing node.js things like Typescript compilation. Finally you can assemble Docker/OCI images using rules_docker and js_image_layer which prevents the need for Dockerfiles at all, creates images with just exactly the dependencies needed (instead of the huge node_modules base layer which would need re-generating and downloading anytime a single dep changed) and better yet can be built pretty much instantly in most cases because it doesn't run Docker to do it.

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

#142

Post by pastacacioepepe »

eisbaw wrote: post #128
theamk wrote: post #73

Earlier 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.

> the legions of JS developers think the web is the only thing that exists today.

As if all JS developers can be grouped into a single entity with the same thoughts. This sounds a bit like saying "the legions of Makita Tools carpenters think" or "the legions of Volvo truck drivers think".

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

#143

Post by simfoo »

hamandcheese wrote: post #127
jpgvm wrote: 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…

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.

I agree this is one of the biggest weak points of Bazel. It lacks a distribution that provides all these goodies out of the box, with maintained and documented workflows. Setting up hermetic builds and remote caches, builds & execution requires a whole team of experts right now.

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

#144

Post by hamandcheese »

IshKebab wrote: post #132
hamandcheese wrote: post #127

Earlier quoted context omitted.

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.

You have to remember that it was the very first system to even attempt hermetic & deterministic builds. 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?

I wouldn't call it a bazel-like, per-se, but Nix seems to have tamed C++.

I don't think it was easy, though.

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

#145

Post by hamandcheese »

eisbaw wrote: post #129
hamandcheese wrote: post #127

Earlier quoted context omitted.

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.

Bazel plus nix.

This feels like the way, but comes with the huge caveat that it doesn't work with bazel remote execution (unless you can rig up something to sync your nix store to every remote builder).

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

#147

Post by moltar »

renke1 wrote: post #67
palmdeezy wrote: post #47

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…

You can do that with esbuild. Just bundle the handler entry into a single file and esbuild will tree shake the cruft out. That's the approach taken by AWS CDK as well.

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

#148

Post by renke1 »

moltar wrote: post #147
renke1 wrote: post #67

Earlier quoted context omitted.

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…

You can do that with esbuild. Just bundle the handler entry into a single file and esbuild will tree shake the cruft out. That's the approach taken by AWS CDK as well.

Yeah, that always works, of course, even though you might want to externalize certain dependencies still. In this case I don't want to bundle the code (although I might end up doing that, anyway)

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

#149

Post by easton »

renke1 wrote: post #148
moltar wrote: post #147

Earlier quoted context omitted.

You can do that with esbuild. Just bundle the handler entry into a single file and esbuild will tree shake the cruft out. That's the approach taken by AWS CDK as well.

Yeah, that always works, of course, even though you might want to externalize certain dependencies still. In this case I don't want to bundle the code (although I might end up doing that, anyway)

You can give esbuild a list of dependencies that you want to be external and it won’t bundle them, I’ve done it with the AWS SDK and it works as expected.

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

#150

Post by underdeserver »

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

If I understand this correctly -

This means that #ifdef FOO will be evaluate to true _inside the .cc and .h files listed in srcs_, when building this target or dependent targets, but might be something else when downstream targets' object files (.o) are built.

Post reply on HN