at logo


A monorepo is a single repository that contains many other projects/packages/libraries, the monorepo has been championed by google who reportedly have all their code in single repository totalling billions of lines of code with tens of thousands of thousands of developers working on it.



One of the main benfits in using a monorepo is in developer onboarding, whatever size of company you are its likely theres a decent amount of learning and knowledge sharing that has to be done before a new start can actually run your whole app locally and start to make changes. Of all the places I have worked the larger the company generally the more difficult this, all the more difficult with the shift to SPA everything, its possible there are integrations that they never know about because their in another repo on another porject with another team. This then becomes a barrier to sharing work/knowledge around, leaving certain teams and people responsible for certain bits of code. With a monorepo a new developer only has one repo to pull and understand how to make changes and test those changes, often in an enterprise environment different teams can use different tooling and even process to contribute code, with a monorepo centralising and standardising should be easier.

Integration & Sharing

The tedious task of bumping versions up the dependency tree would be no longer, "every commit is a release" and every other team and developer would have the latest changes. Sharing code between packages would be easier probably more common, often the overhead of repository management can decide that sharing code is'nt worth the management pain. Integration testing would be made easier from the outset rather than an after thought, often the integration of two packages is not tested until moved to the test team, in a monorepo developers should be able to work on the whole flow rather their own isolated code.


Making large refactors, updating package versions, find and replace or codemods should be easier, backed up with integration tests giving greater confidence in the changes made and easier depedency management and version bumping.


The main issue with managing a monorepo is tooling, Lerna is a popular tool for managing a single repository of npm packages, but changes to your build or deployment pipeline would be required depending on your setup. Github has not long added code owners allowing certains bits of a repo to be managed by different people.

I think it most cases a monorepo would provide a better developer experience and make writing better solutions easier which would outway the cost of supporting a monorepo, although like everything it depends on your circumstances.

More reading
Site published