A monorepo is a single repository that contains all code for a company, team, or product rather than having separate repositories. Key advantages of a monorepo include consistency across language versions, dependencies, and code style which makes upgrades and refactors easier. However, a monorepo also has disadvantages such as a more complex build process, inability to version internal libraries, and difficulty searching and managing the large codebase. While a monorepo provides benefits like easy code reuse and setup, the tradeoff is less flexibility and potential slowdowns from the large size.

1. Advantages and
Disadvantages of a
Monorepo
Ian Davidson

2. What is a Monorepo
Rather than having separate repositories for each project, all code is stored in a
single repository. The boundary of a monorepo can vary and could be for:
○ An entire company
○ A single team
○ A single product

3. Repositories at TextNow
● Originally a single monolith
● Our older services are in written ruby and stored in individual repos
● New services are written in Go and stored in a monorepo

4. Consistency

5. Consistency - Language Versions

6. Consistency - Language Versions
● Only need a single version of a given language
● Upgrades are done together, nothing falls behind

7. Consistency - Language Versions
● Any new project either needs to use an older version or perform an upgrade
● If you want to upgrade a single project, you need to update them all
● Can use side by side upgrades to make things easier

8. Consistency - Dependencies
● Can define one set of dependencies, and keep their versions the same
● All dependencies are fetched from the start
● Upgrades are done at once, nothing falls behind
● Easier to avoid redundant packages
● Package management is consistent

9. Consistency - Dependencies
● Not all dependencies are needed by everyone
● Upgrading for a single project requires upgrading for all projects

10. Consistency - Style
● Any code style and formatters can be shared and updated together
● Code is more readable
● Project format is easier to enforce

11. One build
● A single build for your entire repo
● You don't build a project, you build the repo
● Easier to catch bugs/breaking changes
● Clients and servers can be developed and tested together
● All projects are built at once, so changes are ready for deployment right away
● Build can be fully tested

12. One build
● More complex build process, can take longer
● A build doesn't truly represent reality
● Easier someone else to break your build

13. Code Reusability
● Easier to make use of code that others (and you) have already written
● Other developers can contribute and improve existing libraries
● No need for internal libraries

14. Code Reusability - No Internal Libraries
● No need for external dependency graph
● Easier to avoid cyclical library dependencies

15. Code Reusability - No Internal Libraries
● Unable to version any internal libraries
● Harder to open source – would have to move out of the monorepo

16. Code Refactoring
● Easier to make large scale refactors
● Catch any breaking changes easily
● All changes are immediately shared

17. Setup, Tear Down, & Maintainability
● No need for any boilerplate or admin work for what would be a new repo
● Hooks, helper scripts already exist and stay up to consistent
● Commit a new project, everyone has it
● Unused code and projects can just be deleted

18. You have everything!
● One repository – easier setup
● Anything new added, everyone gets
● Finding what impact your change make is easier
● Able to dig through other services
● No forgotten repos

19. ...but do I want everything?
● Sheer volume of code can make setup slow and daunting
● Updates can take a long time
● General searching can be more difficult
● Everyone can see all code, can't make true abstraction
● A good portion of the codebase is unneeded for each developer

20. High Scale Version Control
● In a large code base with a large amount of contributors, version control
becomes complex
● Merge conflicts become increasingly likely
● A large enough repo can't be stored on a single machine
● May need to change version control systems, only checkout a subset of
the monorepo (git lfs)
● But then we've lost some of the benefits

21. Summary
● Repo setup takes more work, but only needs to be done once
● Consistency is easier to enforce, but changes require more work
● Dependency management is shared
● Upgrades are carried out together
● More consistency, less flexibility
● You have everything you'll ever need and everything you never wanted

22. Thank you.