Monorepo

The common wisdom in dev community is to break our code into separate repo if the functionalities can be standalone. This is to avoid a giant source code repository where everything under the sun being lumped in together. Instead, separate small repos being pulled in together using some sort of dependencies management like pip, npm, composer, gem or built-in vsc tools like svn externals or git submodule.

But there are some prominent organizations that prefer the traditional approach of single and large code repositories, loosely known as monorepo.

Monorepos aren’t strictly superior to manyrepos. They’re not strictly worse, either. My point isn’t that you should definitely switch to a monorepo; it’s merely that using a monorepo isn’t totally unreasonable, that folks at places like Google, Facebook, Twitter, Digital Ocean, and Etsy might have good reasons for preferring a monorepo over hundreds or thousands or tens of thousands of smaller repos. - http://danluu.com/monorepo/

Linux kernel is monotree, not monorepo. But still, this make a point against manyrepos - http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html.

Even Windows adopting monorepo - https://www.visualstudio.com/learn/gvfs-design-history/.

From one of our member:-

We use one big monorepo. Even though we have a bunch of separated services it still makes things like updating their APIs much easier as you can update the call points as well in the same commit.

Q: what about modules that can be used by different project, do you factor that out from the monorepo ?

Yes those get their own repo and are included as git submodule in the mono-repo.

Another member said this:-

We have a monorepo for wordpress development. More than dozen of plugins sitting in a repo. A few thing i find convenient with this approach.

1. reusing code is easy.
2. a common convention is shared between all plugin.
3. a config file that toggles which plugin/file to run at runtime. Easier to troubleshoot stuff.
4. a weird problem once fixed, its fixed for all plugins, and the solution is shared between all plugins(no more extra thinking).

Problems:

1. Commits from multiple different project into one repo . To make commit message more sensible, i veto mandatory issue key in commits.
2. Folks can't understand why certain convention/code exist.
3. PHP namespace is global. Namespace clashes when plugins from the same monorepo is being loaded into wordpress.

I was thinking about offloading a lot the dependency management to composer/bower(for js,css asset)

http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository (archived)