Why use a Monorepo

Advantages of a monorepo:

• Shared code and visibility. Co-location makes it easier to share any and all code. Far less overhead than extracting packages, publishing them to [[npm]], etc.
• Consistent developer experience. A monorepo adds friction to creating inconsistency. If you're already using a unit testing library, it's easier to conform than adding a new one. This makes it easier for developers jumping from project to project
• Single set of dependencies. [[20221215112341-single-version-policy]]
• Atomic changes. Both the frontend and backend can be changed in a single commit. No need to consider breaking changes in the API. Rolling back is also simpler.

Over time, I've found that atomic changes are the real power. It increases the speed of changes, and makes experimentation easier as the creators and consumers are co-located. Really great for things like [[designsystem]] [[breaking changes]].

To make a monorepo work though, you need adequate tooling. Otherwise you run into maintainability problems at scale:

• Efficiently running tasks across multiple boundaries. e.g. how to test app1 and lib1, without everything else
• No enforcement around code boundaries - things can quickly become a tangled web.
• Tooling anarchy, with each app/lib using its own setup.

Note: for a monorepo to truly work, teams have to be comfortable making changes in code that they don't own. Otherwise walls start to be built, and the advantages of a monorepo slip away. Things like 'free dependency upgrades' are never truly free - someone has to do the work. If team's aren't able to do that work and have it apply to everyone, a monorepo may not be worth it.

A monorepo is not a monolith. You can have a monorepo in a monolith, but the two are not connected. Even though code is co-located in both, a monolith requires everything to deploy and run together, which is usually the core problem.

Something I've yet to try is multiple monorepos across the organisation. In theory this is related to [[20230130013734-domain-driven-design]], and [[20221010033955-single-responsibility-principle]]. Code that changes together should be located together. Otherwise, it can be separate.

[[20221107045937-monoliths]]

[[monorepo]] [[nx]]