monorepo.tools VS large-monorepo

I'm surprised this isn't getting any attention. Reading the docs, sounds very promising, thanks for creating this! I see Nx, Turbo and Moon being mentioned in passing in [Alternatives & pitfalls](https://onerepo.tools/concepts/why-onerepo/#alternatives--pi...), but a more in-depth comparison would be interesting. At least something that could be a column in the table at the bottom of [monorepo.tools](https://monorepo.tools/#tools-review).

> I don't think anyone coming from a multi-repo world really understands the full implications of a monorepo until they've worked in a large scale one

That's entirely fair. My sole experience is the one black-sheep monorepo at my own relatively-recently joined company, which is nowhere even close to approaching true large scale.

Genuine question, though - what _are_ the advantages, as you see them (you didn't explicitly say as much, but I'm reading between the lines that you _can_ see some)? Every positive claim I've seen (primarily at https://monorepo.tools/, but also elsewhere) feels either flimsy, or outright false:

* "No overhead to create new projects - Use the existing CI setup" - I'm pretty confident that the amount of DX tooling work to make it super-smooth to create a new project is _dwarfed_ by the amount of work to make monorepos...work...

* "Atomic commits across projects // One version of everything" - this is...actively bad? If I make a change to my library, I also have to change every consumer of it (or, worse, synchronize with them to make their changes at the same time before I can merge)? Whereas, in a polyrepo situation, I can publish the new version of my library, and decoupled consumers can update their consumption when they want to

* "Developer mobility - Get a consistent way of building and testing applications" - it's perfectly easy to have a consistent experience across polyrepos, and or to have an inconsistent one in a monorepo. In fairness I will concede that a monorepo makes a consistent experience more _likely_, but that's a weak advantage at best. Monorepos _do_ make it significantly harder to _deliberately_ use different languages in different services, though, which is a perfectly cromulent thing to permit.

The section on what monorepo tools should provide is useful if you are planning to set up an enterprise-level monorepo.

The next step would be to familiarize yourself with the codebase. Most of the repositories use monorepos for organizing and managing their code. A rule of the thumb here would be to make yourself familiar with what component lies in which place. It is next to impossible to understand the entire codebase at once. For starters, you can:

Monorepos are a great concept, especially in environments like Node.js which encourage having many small packages.

You might want to use monorepo tooling like NX, Lerna, or Turborepo to guide you. https://monorepo.tools/ has a list of tools.

This explains it really well: https://monorepo.tools/

Have a look here to get some good context around monorepo tooling and if it’s something you actually need and want to do - https://monorepo.tools Some of the monorepo tooling can be a steep learning curve so you want to really think about the problem you are trying to solve and whether the effort will be worth it

The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn't used. The benchmark results at this repo showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.

At Nx, we’ve heavily embraced Typescript from the beginning and we’ve been very happy with that decision. Nx also stands as the fastest JS monorepo tool available, demonstrating that adopting TypeScript does not necessarily compromise speed. However, we don't stop here. To push the boundaries further, we started to rewrite the most performance critical and computationally intensive parts of the Nx core in Rust.

You can see our results and the details of the benchmark - and even run the benchmarks for yourself in this repo.

Performance is at the core of what we do at Nx. Hence it isn't surprising that Nx is the fastest JS-based monorepo solution out there. We've shown that a couple of times. But every millisecond counts! As such, we decided to experiment with Rust to see whether we could further optimize our project graph creation as well as the hasher function that is used for the computation cache.

Speed - we drastically improved the speed of Nx, making it the fastest monorepo solution in the frontend space.

Up until Lerna v4, either the p-map or p-queue npm packages have been used to delegate the task scheduling. With v5.1 we introduced nx as an additional mechanism to schedule tasks. The advantage? Nx has caching built-in, which also gives Lerna caching support, making it lightning fast. A recent benchmark test resulted in Lerna being 2.5x faster than Lage and around 4x faster than Turbo (as of Oct 2022; test it out by yourself).

Nx is faster than most of the current available alternatives. See the corresponding benchmark repository

Delegating task scheduling to Nx allows to speed up any Lerna workspace in the range of 2-10 times. Check out our public benchmark which compares Lerna with other popular JS based monorepo tools.

(as always, feel free to reproduce it here)

But let's do some more real "apples-to-apples" comparison of Lerna's speed with useNx enabled. For benchmarking Nx we have set up a repo in the past which we regularly use to measure the speed of new Nx releases with other similar tools on the market such as Lage and Turborepo: https://github.com/vsavkin/large-monorepo. We now added Lerna+Nx (Lerna with useNx enabled) to that repo to measure the impact.