Monorepo vs polyrepo for a design system
repo architecture trade-offs.
atomic cross-package changes and shared tooling versus build orchestration, caching, and versioning complexity.
blanket pro or anti stance ignoring release and CI implications.
What's really being asked
This checks whether you can weigh repository architecture against the concrete needs of a design system: many interdependent packages, shared docs, and coordinated releases.
The full answer
Benefits of a monorepo. Atomic commits let you change a token, the component using it, and its docs in one reviewable PR, impossible across split repos. One shared toolchain, TypeScript config, ESLint, and test setup, removes duplication. Components, the docs site, and design tokens import each other directly without publishing intermediate versions. Tools like Turborepo or Nx add a task graph with remote caching and affected-detection so CI only rebuilds and tests what changed. Challenges. You must define and maintain a dependency graph and avoid circular deps. CI needs affected-package detection or it rebuilds everything. Releases require a deliberate strategy: fixed versioning bumps all packages together, independent versioning needs Changesets or Lerna to compute per-package bumps and changelogs. Onboarding and clone size grow, and tooling must scale to the repo.
The mistakes people make
Saying monorepos are always better while ignoring build orchestration and release complexity. Saying separate repos are simpler while ignoring the pain of coordinating cross-repo changes and version bumps. Forgetting caching and affected detection, leading to slow CI.
What usually comes next
Fixed versus independent versioning, and which suits a design system. How do you keep CI fast as packages grow. How do you prevent circular dependencies.
A concrete example
With Turborepo, changing a spacing token and the Card that consumes it lands in one PR; affected-detection rebuilds only tokens, Card, and the docs site, remote cache skips the rest, and Changesets generates the correct per-package version bumps on release.
Interview question
What is the most important reason a monorepo's CI needs affected-package detection for a design system?
- a.It avoids rebuilding and testing every package when only a few changed, keeping CI fastCorrect
- b.It is required to publish packages to a private registry
- c.It automatically resolves circular dependencies between packages
- d.Without it, packages cannot import each other across the repo
Why? this is the answer
Affected detection limits CI work to changed packages and their dependents, preventing full-repo rebuilds as the system grows. Cross-package imports, publishing, and circular-dependency resolution are separate concerns it does not handle.
Just read this? Test yourself on what you have been reading.
Read the original → monorepo.tools
- #monorepo
- #turborepo
- #nx
- #design-systems
- #tooling
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