Understanding monorepo in JS ecosystem
Monorepo allows developers to work in the single space where all projects live and their connections are visible. It simplifies cross-project changes, code and tooling reuse and encourages consistency and standardization. The expense is the overal codebase size and complexity, slower setup and less freedom given the consistency and centralisation. These points are critical especially for newcomers. Additional tooling may be required to manage the repo as well as additional docs to explain repo structure with respect to each stakeholder.
Managing multiple packages in monorepo
If the monorepo contains single package, no additional tooling is required. Otherwise it’s needed to use a tool to manage multiple packages. npm recently announced workspaces, a lower level feature that allows multiple projects (packages) to live within one repository. A higher level tool may be utilized to simplify monorepo management. The most popular tool in this category is Lerna. Lerna helps with dependency management, versioning, publishing and running scripts within many individual packages in monorepo using single command. Lerna also allows to import packages to a monorepo while keeping their git histories.
Side effects and future developments
Dev tooling, config and code-style sharing adoption is expected with monorepo.
Future project requirements may be better satisfied with monorepo. For example if the projects’s next opportunity lays in cloud-sync service, it will be desirable to share critical schemas and typings in standalone package within monorepo.
Managing multiple repositories
An alternative to mono and multi repo is meta repo, which allows to manage multiple repositories from single point e.g. create branch for a feature or commit in multiple repositories by single command. Additional cost of learning, setup, using and maintenance of meta-repo management tool must be considered though.
The meta repo approach brings access management opportunities. A standard mono-repo gives access to all the code whereas in meta repo, we can work on specified subset of repositories as if they were mono-repo. This is be useful in cases where its required to restrict developers access to the code.
Many & monorepo comparison table
| Multiple repositories | Monorepository |
|---|---|
| philosophy | |
| more decentralised | more centralised |
| cognitive load | |
| 1 logical project | >= logical projects |
| 1:1 of repo to package | 1:n of repo to packages |
| smaller codebase complexity | bigger codebase complexity |
| difficult global cross-project overview | easier global cross-project overview |
| development | |
| low global code visibility | high global code visibility |
| difficult code reuse | easy code reuse |
| faster setup, builds and tests | slower setup, builds and tests |
| discourages consistency | encourages consistency |
| granular version information | allows unified versioning |
| hard cross-project changes & refactoring | simplified cross-project changes & refactoring |
| difficult global code review | simple global code review |
| difficult integration tests | easier integration tests |
| difficult dev tooling and config sharing | simple dev tooling and config sharing |
| open source tool and IDEs standard | less tooling and IDEs support |
| culture | |
| more individualistic | team unification & collaboration across teams |
| less activity | more activity |
| multiple places to submit issue | one place to submit issue |
Sources
- ‘Advantages of monorepos’. [Online]. Available: https://danluu.com/monorepo/
- N. Brousse, ‘The issue of monorepo and polyrepo in large enterprises’, in Proceedings of the Conference Companion of the 3rd International Conference on Art, Science, and Engineering of Programming, Genova Italy: ACM, Apr. 2019, pp. 1–4. doi: 10.1145/3328433.3328435.
- G. Brito, R. Terra, and M. T. Valente, ‘Monorepos: A Multivocal Literature Review’, arXiv:1810.09477 [cs], Oct. 2018, Accessed: Oct. 08, 2021. [Online]. Available: http://arxiv.org/abs/1810.09477