Turborepo 1.2: High-performance build system for monorepos

> There are a huge number of mostly non-JS-specific problems that monorepo tooling eventually needs to solve: distributed build artifact and test result caching, distributed action execution, sandboxing, resource management and queuing, observability, and integration with other CI tools to name a few.

Turborepo author/founder here....

I agree. I built Turborepo because existing tools weren’t meeting our needs.

To solve these problems and still be flexible, many existing build tools end up with lots of configuration bloat. We’re trying to avoid that. We want to reimagine the developer experience of monorepo tooling and make it accessible for everyone.

We're discussing more native support for other languages. It would likely be a commitment to a small subset of popular languages (e.g. Rust, Go, C++, Python) while still maintaining our goal of nearly zero configuration.

https://news.ycombinator.com/item?id=30959607

The primary difference is that in Nix it's fairly easy to wrap arbitrary build systems, so you can inject third-party dependencies into your codebase without vendoring and adapting their build system (plus, through nixpkgs[0], the majority of all relevant software has already been wrapped).

In Bazel you have to do a lot of that work yourself. Google has essentially ~unlimited manpower to do this for the things in their third_party tree, but for any other size of organisation this is not the case and people resort to all sorts of ugly hacks.

Depending on your needs these different types of projects can also coexist with each other in Nix. To use an example from my work, we have a Nix-native build system for Go[1] and code using this[2] co-exists with code that just uses the standard Go build system[3]. Both methods end up being addressable on the same abstraction level, meaning that they both turn into equivalent build targets (you can see both in a full build[4] of our repo).

And for what it's worth, some of the things Bazel gets extremely right (such as having a straightforward mapping from code location to build target, universal build command) are pretty easy to do in Nix (see readTree[5], magrathea[6]).

[0]: https://github.com/NixOS/nixpkgs

[1]: https://code.tvl.fyi/about/nix/buildGo

[2]: https://cs.tvl.fyi/depot/-/blob/ops/besadii/default.nix

[3]: https://cs.tvl.fyi/depot/-/blob/third_party/gerrit-queue/def...

[4]: https://buildkite.com/tvl/depot/builds/13067

[5]: https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md

[6]: https://cs.tvl.fyi/depot@f0e6d3498d6c0f905977ea9432c311b6808...

The main thing to be aware of with Bazel is its sandboxing philosophy. Instead of using the files in place, it basically creates a copy of the relevant file structure for any given build (i.e. minus the files that might exist on a given folder but be irrelevant for a build). Because of this, it generally requires strict hermeticity guarantees from everything you're doing, so many things have to be done in a "Bazel way" (i.e. there are specific ways in which you're supposed to download dependencies and there are restrictions in terms of file creation in e.g. tests that might deal w/ I/O)

The way that Bazel approaches flexibility is by being programmable (via a Python-like language called Starlark). There are open source rulesets for various languages that you can use to get off the ground faster, but they are usually fairly opinionated, so if you want to deviate from the happy path, you're going to hit face first into a fairly steep learning curve about depsets, graphs, file/symlink permissions and the like.

Another "weakness" of Bazel is that it's not aware of ultra granular file-to-file dependencies out of the box (e.g. how Golang imports work vs Java's), so either you have to manage dependency graphs manually or you invest in wrapper tooling like gazelle to automate some of the BUILD file generation for you.

>I'm sad JS needs a build step. The best build system is none at all IMHO.

Good news: JS doesn't need a build step. Modern webdev wants a build step mostly because it wants Javascript to feel more like a "serious" language. There are technical benefits to compiling to Javascript, most of which can be served by other means, but the unnecessary complexity of the Javascript ecosystem is mostly about gatekeeping and aesthetics and i will die on that hill.

>I'd love to see native support everywhere for typescript or other things we typically depend on a build for today.

Typescript is part of the problem. You can literally just accept Javascript for what it is - dynamically typed - and write it like any other scripting language.