Monorepo: Managing Multiple Projects in One Repository
A monorepo puts multiple projects into one repository, creating a single source of truth. It's great for design systems, allowing atomic updates to shared components and consuming apps.
Why it exists
Managing dependencies and ensuring consistency across many separate repositories is complex. A change in a shared library requires updating and deploying every project that uses it, leading to versioning conflicts. Monorepos were created to solve this by centralizing code and simplifying cross-project changes.
The mental model
Think of a monorepo not as one giant project, but as a city containing many distinct buildings (projects) that all share the same infrastructure (build tools, dependencies). A change to the city's power grid (a shared library) can be instantly verified against every building it affects, all within a single commit.
How it works
All code for multiple distinct projects (e.g., a web frontend, a backend API, a design system library) lives in a single Git repository. Specialized tooling is crucial to manage this. These tools understand the dependency graph between projects, so when a file is changed, they can run tests and builds for only the affected projects, avoiding a full rebuild of the entire repository. This allows for atomic commits that span multiple projects.
When to use it
Use a monorepo when you have multiple projects that are tightly coupled or share significant code, like a component library used by several frontends. It simplifies dependency management (no need to publish and consume internal packages) and enables large-scale atomic refactors. Companies like Google, Meta, and Microsoft use them to manage massive, interconnected codebases.
When not to use it
Avoid a monorepo if your projects are completely unrelated and developed by siloed teams with no shared dependencies. The overhead of specialized tooling and the potential for a slower version control experience (e.g., large checkouts) can outweigh the benefits. If teams need full autonomy over their toolchains and release cycles, multiple repositories are a better fit.
One canonical example
A design system team manages a shared component library in a monorepo alongside three web applications that use it. When they update a Button component, a single pull request can contain the change to the library AND the necessary adjustments in all three applications. The CI pipeline automatically tests the component and all three apps, ensuring no breaking changes are introduced. This single, atomic commit guarantees consistency across the entire product suite.
Interview question
What is a primary benefit of using a monorepo, especially for projects with shared components?
- a.It simplifies the process of making coordinated, atomic changes across a shared library and all its dependent applications.Correct
- b.It allows each project to use entirely different build tools and programming languages without conflict.
- c.It completely eliminates the need for any version control system or external package management for internal dependencies.
- d.It ensures that every project within the repository can be deployed independently without any shared release coordination.
Why? this is the answer
The card highlights that monorepos enable "atomic commits that span multiple projects" and simplify "large-scale atomic refactors," as seen in the design system example where a single change updates a shared component and all consuming applications. Distractor D is incorrect because monorepos often facilitate coordinated releases for shared components to ensure consistency, rather than promoting fully independent deployments without coordination.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #monorepo
- #version control
- #build systems
- #design systems
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles