buck2
https://github.com/facebook/buck2>
https://hub.docker.com/r/chainguard/buck2>
https://www.google.com/search?client=firefox-b-e&q=hacker+news+buck2+>
https://news.ycombinator.com/item?id=35470371>
buck2 is arguably the state of the art currently, it is developed by meta based on the learnings from their own buck tool and bazel(/blaze), and others:
https://news.ycombinator.com/item?id=41122736>
Buck2 is IMO much better than even Bazel is from a design POV, because it actually cleanly separates all user rules from the build engine, and has a coherent modern design around a sound theoretical basis. Neil, one of the leads and author of this post, has written many build systems, so it’s not like he’s unaware of Bazel; his taxonomy of build systems and ones like Bazel in “Build Systems a la Carte” is worth reading even for Bazel users. It also has a snappy UX and is fast on the command line, which Bazel still lags at a bit. Bazel has all the mindshare, though, and a lot of good features and libraries. But Buck2 is in a different league from Buck1 completely, and in many ways even from Bazel, IMO.
https://news.ycombinator.com/item?id=35472263>
https://news.ycombinator.com/item?id=35470953>
bazel bad
https://www.reddit.com/r/ExperiencedDevs/comments/18a49st/thoughts_on_bazel_and_monorepos/>
Monorepo versus multirepo isn’t even a choice in many cases, IMO. Forget about visibility and other concerns for a moment… once you have tightly-coupled components, you will not make that go away by moving them into separate repos. Many projects pretend to have multirepos but in reality it’s one big project managed on a different level as a monorepo, even if that’s just deployment tooling or something like Google’s “repo” tool / Git submodules. At the very least, you kinda have to bump versions when you make any change that breaks backward- or even forward-compatibility, if nothing else (edit: which could easily mean dozens of PRs in pathological cases or an integration repo). Or you don’t do it, but pay dearly in terms of reproducing / rolling back changes or reliability.
The only reasonable way to get loosely-coupled or decoupled components is to design some stability and generality into the stuff, to stand on its own, and to have dependencies point a certain way. The prototypical example is public libraries, which provide a stable API and your stuff depends on it.
I like mono repos. Originally my organization tried multiple repos and we just got absolutely buried under the weight of having developers having to checkout several repos and manage dependencies between them. Then code flow was also a nightmare that took a long time to flow from a core repo through the repo dependency tree.
https://www.reddit.com/r/ExperiencedDevs/comments/18a49st/thoughts_on_bazel_and_monorepos/>