search

nrwl / monorepo.tools

Your defacto guide on monorepos, and in depth feature comparisons of tooling solutions.
https://monorepo.tools
MIT License
290 stars 31 forks source link

Content feedbacks #29

Closed y-nk closed 2 years ago

y-nk commented 2 years ago

Hi! I just discovered this and it's honestly a good reading, especially the references and articles are pretty useful and I wished I had this when I started my journey into monorepos :) I'll try to leave aside things related to #18, but I believe some might be entangled, so sorry already.

1. npm monorepos vs others

It looks like the website has some bias towards npm-oriented monorepos (...because it's made by nx?).

The fact that Bazel is a truly language agnostic monorepo seems totally eluded under a simple "Consistent tooling" umbrella which consists of a single sentence but imho this is a major point to look at when searching for a monorepo solution.

At the time I've started my researches, this was probably the biggest point of decision: we had a tree of "npm/non-npm" monorepo solutions, and then either Bazel/Buck/Pants/Please or lerna/nx/rush. The questioning was mostly in planning, setting up, maintaining our monorepo. I'm not sure if you tried to setup a Bazel/Please monorepo but it is light-years away from setting up a nx/lerna/rush/turborepo monorepo which, even though are quite different between themselves, look all pretty similar compared to those non-javascript monorepos.

Either Bazel should not be here, or either imho you should have a separate section describing the pros/cons of Bazel-type (let's say BUILD-file based monorepos) vs more integrated/opinionated npm-oriented solutions. You may argue that "nx is pluggable" but a user would still carry the node runtime to build your stuff anyhow, where solutions such as Please have portable binaries to avoid such a cost (i'm talking about the monorepo toolchain, not the project's ones). On the other hand, by nature npm-oriented solutions will have greater focus/capabilities in caching dependencies because there's a greater relationship to npm, where broader monorepos would just elude this and delegate to either a language-specific toolchain or the build script itself. It's a game of pro and cons, but it should be stated.

...and if Bazel is here, i guess it's fair that related competition should also be represented: Buck, Pants, and Please (to only name those I've tried).

2. eluded pricing

There's also a great shade around the "opacity" of the toolchain and the features which claim to be available but not mentioned if free or paid. I think that, if you truly want to be informative you have to be impartial and shouldn't hide that some of nx and turborepo features are part of a paid plan. One of the major reason why we didn't choose nx at the time was the learning curve and the necessity for a staff to learn a framework - i think that nx is much more an hybrid of monorepo/framework due to the tons of generators/etc which come with (not that i dislike it personally, but it has to be said).

I realise typing this that it's a lot already so i'll stop there. Happy to help.

vsavkin commented 2 years ago

Thank you for opening the issue.

The main target audience for the website are JS folks. The support for other technologies is important cause a lot of JS workspaces have non-JS projects in them, but the focus in on JS. The main reason is that adding variability and covering the topic more generally makes it harder to compare and makes the resource less useful. Even in the current state having both Lerna and Bazel in the same list is a bit weird cause they are nothing alike. Nx is a lot closer to Bazel than Lerna, so comparing Nx and Bazel is coherent. Comparing them to Lerna is not as helpful.

In other words, the notion of a "monorepo" is already underdefined in the JS space alone, hence the confusion. Expanding the scope would make it even less concrete, so we decided against it.

In regards to what is free and paid, Nx (and I believe Turbo) allows you to run your own impl of the distributed cache or in case of Nx distributed builds. Some of our clients do :) So I'm not sure if there is a fundamental distinction here between say Bazel, Nx, and Turbo. In case of Bazel, you will have to have some service that implements the Bazel remote build protocol. You can either implement and host it yourself or use an existing one.

We tried not to include any features of Nx Cloud that are very hard to implement yourself (UI, analysis, stats) even though those features are super important for any non-trivial monorepos (You cannot use a non-trivial workspace if they only way for you to view your CI logs is in Circle or Azure. Too unstructured, too much noise. You have to have custom UI.).