[renke1]

When I talk about monorepos in our company, I always try to make the distinction between JS monorepo tooling (say nx, turbo or more low-level pnpm/npm/yarn workspaces) and real (?) monorepo tooling (say Bazel). Whereas the latter has more focus on dealing with a wide variety of source code types and artifacts the former is exclusively dealing with NPM packages (which may include other stuff like Go/Rust sometimes). Does this distinction even make sense?

[n42]

I don't know what it is, but it feels like the JS tooling community so often pretends that the rest of the world does not exist in their marketing. I find myself having to dig into docs or the GitHub repo before I figure out what language or ecosystem I'm even reading about.

somehow, the authors of this website neglect to even mention Nix. maybe that has something to do with the fact that this is a marketing page for the tool they named Nx (seriously?).

[renke1]

Yes, I think the JS ecosystem (which I am certainly part of) does sometimes ignore established terminology and solutions from other ecosystems. Although I must say that the JS ecosystem really has amazing tooling in certain areas (say prettier, eslint which I am missing in the Java world for instance).

I was actually about to mention Nix in my post as well. Being a casual NixOS user myself I wonder if there is any kind of monorepo tooling based on Nix? Without ever having used Bazel myself I always thought of it as Nix-like.

[tazjin]

Yes, there is! We (https://tvl.fyi) have been building Nix monorepo tooling for a while. You can see the current state of our repo at cs.tvl.fyi (+ reviews at cl.tvl.fyi and dynamic CI on tvl.fyi/builds).

We use josh[0] to let people clone "just in time" repos with the tooling needed for our setup[1]. We've also started a consultancy (tvl.su) that helps companies move onto this setup, and have customers going for it already.

The reasons we've not been making a lot of noise about this are that we have other large projects(like Tvix[2]) taking up time, and also the integration with customers moving to this setup lets us more confidently figure out what parts we need to smoothen for "non-TVL" use-cases.

As for using Nix in a Bazel-like way, the common experience with Nix is that language-specific build systems are wrapped. This being possible enables projects written in any language to be wrapped in Nix, and integrated in a Nix-based monorepo (something which makes it distinctly more powerful than other solutions).

However, there's nothing in principle preventing Nix from dropping down a layer to the project level itself, and we've implemented (and use) this for Go[3] and Common Lisp[4].

[0]: https://github.com/josh-project/josh

[1]: https://cs.tvl.fyi/depot/-/blob/views/kit/README.md

[2]: https://tvl.fyi/blog/rewriting-nix

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

[4]: https://code.tvl.fyi/about/nix/buildLisp