Monorepo tradeoffs for a design system

WHAT THIS TESTS This evaluates whether you can reason about repository architecture and the operational realities of shipping a multi-package design system, not just name a tool.

A GOOD ANSWER COVERS The core benefit is coordination. A design system spans tokens, primitives, components, icons, and docs; in a monorepo a single PR can change a token and every component that consumes it atomically, with one review and one consistent state. You share tooling once, lint, test, TypeScript config, and build setup, and internal packages link directly without publishing, so local development across packages is immediate. Versioning and release can be coordinated with tools like Changesets. The drawbacks are operational: build and task orchestration get complex, CI must run only affected packages or it becomes slow, the repository and install footprint grow, onboarding requires learning the workspace tooling, and tight coupling can let one package's change unexpectedly ripple. Turborepo and Nx exist to mitigate these via a task graph, remote caching, and affected-only execution.

COMMON WRONG ANSWERS Listing only upsides; senior candidates name the CI and complexity costs. Naming Turborepo or Nx as a benefit without saying what they actually do, namely caching and dependency-aware task running. Assuming a monorepo means a single published package; packages are still versioned and published independently.

LIKELY FOLLOW-UPS How do you keep CI fast? Use affected-only builds and remote caching keyed on inputs. How do you version packages? Independent or fixed versioning via Changesets or Nx release. When is polyrepo better? When packages have truly independent lifecycles, owners, and release cadences with little shared code. How do you stop accidental coupling? Enforce module boundaries and dependency rules, which Nx can lint.

ONE CONCRETE EXAMPLE A team renames a spacing token in packages/tokens. In a monorepo, the same PR updates packages/components that reference it, runs only the affected packages thanks to Turborepo's task graph, hits cache for untouched packages, and publishes new versions of just tokens and components via Changesets. In a polyrepo, that same change would require publishing tokens, then opening a separate PR in the components repo to bump and adopt it, a slower, more error-prone sequence that illustrates the monorepo's coordination advantage and its dependence on good caching tooling.