Monorepos: A Design System's Single Source of Truth
A monorepo places your design system and its consuming apps in one repo. This enables atomic changes: update a component and all its consumers in a single commit. It's ideal for keeping UI consistent, but requires strict tooling to avoid becoming a monolith.
Why it exists
Managing a design system across many repositories (a polyrepo) creates a 'polyrepo tax'. Teams face friction from publishing packages, managing versions, and coordinating breaking changes. This overhead discourages code sharing, leading to duplicated components and inconsistent user experiences. A monorepo strategy eliminates this tax by centralizing related projects.
The mental model
A monorepo is not a monolith. It is a single repository containing multiple distinct projects with well-defined relationships. Think of it as a filing cabinet with separate, clearly labeled folders for your design system, your web app, and your mobile app. They can reference each other directly, without the overhead of packaging and publishing.
How it works
Instead of installing the design system as a versioned package, applications within the monorepo import components directly from the source code. Specialized tooling (like Nx or Turborepo) is essential. It understands the dependency graph, so when you change a shared component, it only rebuilds and re-tests the projects that are actually affected. A breaking change in a library and the corresponding fixes in all its consumers can be bundled into a single, atomic commit.
When to use it
Use a monorepo when you have multiple related projects that share significant code, like a design system and the products that use it. It excels at enforcing consistency, simplifying dependency management, and making large-scale refactors manageable. If you want a change in a shared component to be reflected everywhere simultaneously, a monorepo is the right choice.
When not to use it
A monorepo is overkill for a single project or for completely unrelated projects. The initial tooling setup is more complex than a simple repository. If teams require absolute autonomy—using different tech stacks or uncoordinated release schedules—a polyrepo structure might be a better fit, despite its costs. A monorepo without good tooling is often worse than a well-managed polyrepo setup.
One canonical example
A company has a React-based design system, a marketing site, and a web app, all in one monorepo. A developer updates the primary Button component. The tooling immediately shows how this change affects the site and the app. The developer can update the usage in all affected projects within a single pull request, ensuring perfect consistency is deployed everywhere at once.
Interview question
How does a monorepo primarily facilitate consistent usage of a design system across multiple applications?
- a.By automating the publication of new component versions to all consuming applications.
- b.By providing a centralized package registry for all shared components.
- c.By enabling direct source code imports and atomic commits for shared component updates.Correct
- d.By enforcing a single, unified technology stack across all projects.
Why? this is the answer
A monorepo ensures consistency by allowing applications to import components directly from source code and enabling a single, atomic commit to update a shared component and all its consumers simultaneously. Option A is incorrect because monorepos avoid the publishing step common in polyrepos; changes are applied directly within the single repository.
Just read this? Test yourself on what you have been reading.
Read the original → monorepo.tools
- #design systems
- #monorepo
- #architecture
- #tooling
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles