Building large scale react applications in a monorepo

A monorepo can be described as a repository that contains more than one logical project. These projects can be unrelated, loosely coupled or connected by dependency management tools, they are usually large in size, number of branches, commits and working developers.

React applications are all about components, when developing react apps you’ll be splitting it into components that aim to be reused within different areas of your application or multiple applications.

Sharing code across multiple repositories

Once you start feeling the need to share code across multiple applications you may choose to start creating different repositories and publishing them as npm packages.
As the number of applications and shared components scales you start facing some issues:

Testing: To properly test a shared package you’ll need to locally link several different projects, this can become a daunting task as the number of interdependent packages grows and npm linking can sometimes yield unexpected behaviours.

Publishing: Propagating a fix might require updating and publishing several different interdependent projects in a correct order.

Discoverability: Available reusable components may become hard to find.

Refactoring: Refactoring may lead to updates across multiple packages which then leads to the testing and publishing issues mentioned above.

Friction: If it’s hard to create or update a reusable library, developers will avoid doing it and you’ll either face duplicated code or code put in places it doesn’t belong.

Monorepo != Monolith

When you have all your codebase within the same repository it’s tempting to fall into the trap of creating a monolith (a gigantic application where all parts are intertwined with each other) so we need to ensure that modularity is a first class citizen within these repositories.

Separating the different pieces of these projects within their own subfolders is not enough, within these projects components are still independent packages that can be developed tested and published independently.

Each package has clearly defined boundaries and ownership.