Lesson 16 of 30

Monorepos & Package Management

Q: Why would a company choose a monorepo over separate repositories for its apps and shared libraries? What's the real cost?

A strong answer covers: Monorepos enable atomic cross-package changes — updating a shared library and its consumers in one commit, instead of a publish-then-consume cycle across repos; Workspace tooling (pnpm/Yarn/npm workspaces) handles local linking; a task runner (Turborepo/Nx) handles build caching and affected-package detection; Real tradeoff: coordination/atomicity benefits vs. CI/tooling complexity that grows with repo size if not managed with smart caching.

One repository holding multiple packages that depend on each other — trading the overhead of many separate repos for the ability to change a shared library and every consumer in one atomic commit.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

In a monorepo, you change packages/ui's API and need two apps that depend on it updated to match. How does this typically happen, compared to a multi-repo setup?

In one commit/PR, updating the library and both consumers together, atomicallyThe change is automatically propagated to consumers without any code changes neededMonorepos don't support having multiple independent apps depend on a shared package

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Monorepos & Package Management

What interviewers actually ask about this, and what a strong answer has to cover.

Why would a company choose a monorepo over separate repositories for its apps and shared libraries? What's the real cost?

A strong answer covers

Monorepos enable atomic cross-package changes — updating a shared library and its consumers in one commit, instead of a publish-then-consume cycle across repos
Workspace tooling (pnpm/Yarn/npm workspaces) handles local linking; a task runner (Turborepo/Nx) handles build caching and affected-package detection
Real tradeoff: coordination/atomicity benefits vs. CI/tooling complexity that grows with repo size if not managed with smart caching

Likely follow-ups

How does a monorepo avoid re-running every package's tests on every single change?
Can packages inside a monorepo still be independently versioned and published to npm?
What kind of team or company structure makes a monorepo less appealing?

Practice these with the AI interviewer →

The plain-language idea

A monorepo holds multiple, separately-publishable packages (an app, a shared UI library, a shared config) in one repository, with tooling that understands the dependency graph between them:

apps/
  web/           (imports from packages/ui)
  admin/         (imports from packages/ui)
packages/
  ui/            (the shared component library)
  config/        (shared eslint/tsconfig)

Changing packages/ui and updating both apps/web and apps/admin to use the new API happens in one commit, one PR — instead of publishing a new version of ui to a registry, then separately updating and testing each consumer repo, each on its own timeline.

Monorepos: one repo, no publish step between packagesStep 1 of 3

Separate repos: packages/ui and apps/web live in different git histories — a shared change means publish, bump version, reinstall.

What people usually miss

Watch out

A monorepo isn't "one big app." Each package can still be independently versioned, tested, and even published to npm separately — the repo structure is about co-location and shared tooling, not about collapsing everything into a single deployable unit.
Without smart build caching, a monorepo's CI gets slow fast — re-running every package's tests on every change, even unrelated ones, doesn't scale. Tools like Turborepo/Nx specifically compute which packages were actually affected by a given change and skip the rest.
The real tradeoff is coordination cost vs. discovery cost. Multiple repos isolate teams but make cross-package changes slow and easy to get out of sync (a breaking change published, consumers updating on their own schedule); a monorepo makes cross-package changes atomic and enforceable, at the cost of needing tooling investment to keep it fast.

Why this matters in interviews

"Why would a company choose a monorepo over separate repositories?" is a real architectural-tradeoffs question — the strong answer names the actual mechanism (atomic cross-package changes, shared tooling) and the real cost (build/CI complexity at scale), not just "it's what Google/Meta does."