Is a Monorepo a good idea?

  • What problems in the organisation would a Monorepo solve?
  • Will storing all the code in a single place rather than individual repositories give unnecessary constraints?
  • Should frontend and backend code be in the same code repository?
  • Is the organisation structure/hierarchy set up in such a way which could cause conflict on the approach for shared features?
  • Do you need to share code and by whom will it be consumed?
  • Should code be as close as possible to its consumer and should further abstractions be added when it’s the only option?


  • Shared Features (eg auth, analytics, forms, utilities)
  • Shared Services (Data access, HTTP, PubSub, client state)
  • Branding and styling of User Interfaces (UI)
  • Consistency for User Experiences (UX)
  • Code Linting/Formatting
  • External Packages/Dependencies and their versions
  • Build times
  • Documentation
  • Repository metrics and reports
  • Deployment config/coordination
  • Deployments for different environments
  • Prototypes and Spikes
  • The responsibility of shared code
  • Intellectual property
  • Access for internal staff, outsources and contractors
  • A codebase with many contributors
  • Monorepo
  • Reference Repository
  • Polyrepo
  • Copy and Paste


Pros (Perceived)

  • Easier to maintain external packages/dependencies (complexity is added with more languages)
  • Single store for code styles, formatting and linting across solutions
  • Everyone knows what everyone is working on via the PR’s on the same repository
  • Packages can also be released as NPM packages if required
  • Tests can be run across all platforms when a change is made to a shared service/feature/package

Cons (Perceived)

  • Yet another CLI
  • Won’t solve external dependencies issue
  • Overly complex for small projects
  • IP for all projects in a single place
  • Restricting access to apps/libs for certain teams/outsourcers
  • Possible longer build times
  • Repository size
  • Organisation Structure
  • Other opinion based reasons :)

Reference Repo

  • Shared Styles
  • Shared Services
  • Building apps (base build and deployment config)
  • Linting/formating


  • Shared packages can be kept in sync across platforms


  • Loads of code that might not be required in a fork
  • Requires discipline to merge in the reference repo as often as it changes
  • The fork can easily get out of sync with the reference app
  • Do not know if a change in a shared package will break something in a fork until it is merged, which might mean it will never be merged



  • Public packages are good for PR in the engineering community with supporting Articles and Blogs
  • Clear responsibilities


  • Time-consuming to maintain and developers will always take the path of least resistance
  • Another layer of security is required (AuthTokens) when accessing Private packages

Copy and Paste


  • Quick and dirty — easy to get quick results


  • Well…







Software Engineer —

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Who is 261112 Systems Analyst?

Introduction to Flutter

Asa critical care medicine specialist, I am used to seeing the sickest of the sick.

How to hire the best Software Developers

Implementing Agile @ Zomato

How to Create Your Own PCB Board — The Engineering Knowledge

Adding Additional Enemies

What is Embedded Analytics? How Tableau embeds to Salesforce in hig?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Stuart Tottle

Stuart Tottle

Software Engineer —

More from Medium

A Flexible Way of Building

A pragmatic guide to structuring complex frontend codebases

Let’s extend Ant Design

Global variables using Styled Components