[jayd16]

Monorepo comes with its own set of challenges. Git doesn't scale all that well but is the most popular and supported VCS.

Assuming you get as far as actually having code in one repo, the advantages of monorepo do not come for free. You either use a consolidated build system or you're still linking code using packages. A mono-build is no small task especially if your org is of any sort of complexity.

You'll almost certainly never get away from packages entirely unless you want to pull in the source code of all your dependencies. Not only are you merging it in but you're integrating it into your mono-build system. Doesn't sound feasible or enjoyable to me.

Some people consider mono-repo a fools errand. At most places you can take the pragmatic approach of consolidating repos where it makes sense while keeping the decoupling advantages of packages where it makes sense. They both have trade offs.

[drewcoo]

Believe it or not, there is not only one way to do a monorepo.

It's still possible to have different jobs for different projects, just like before, with some kind of build filter in front of them. Those different build jobs can be managed however they are now. This is common. There is no need for a single giant build mechanism that knows all the things.

Packages are a separate concern. And of course you should use versioned packages, just like you always have. Why re-invent a solved problem? Trying to force library upgrades in n-many services all at once, automatically, is a hard problem. Why invent that, too?

Repo consolidation really shines for me in infrastructure and testing - the things that can touch multiple services at once. That's stuff most devs aren't really involved in day-to-day. I think that a lot of the monorepo hatred comes from not understanding other people's problems.

[jayd16]

If you're using versioned packages, how does a mono-repo make sense? At least, what is the point? If your build machine creates the package, you can't even push the package update and the consumption of the package in the same commit.

[NomDePlum]

Doing exactly this at a new organisation I recently joined.

We are treating it as an experiment. Got 2 teams with 5/6 Devs in each sharing the same monorepo. We are using nx.dev as the build tool and it's going pretty well so far.

Different tech stacks too but using nx.dev thats been abstracted away. Allows us to share practices and we've built out the CI/CD and supporting infrastructure on AWS together which has certainly saved duplication of effort. Possibly one more team coming on board too.

If in the future it's not paying off we can always split. Doesn't need to be a forever decision, is how we are viewing it.

[curlftpfs]

What do/don't you like about Nx?

You describe my scenario (with fewer teams), difficult deciding between options. (Using Webpack + git to do "component management" and bundle to single-file ES6 modules.)