Frontend Monorepos: Turborepo, Nx, and the State of 2026

By /
⏱ 2 min read

Monorepos have gone mainstream in frontend. Most companies of meaningful size now run a monorepo for their web platform. The interview increasingly probes whether you understand the tools, the ergonomics, and the real-world tradeoffs.

Why monorepos

  • Shared code without npm-publish friction
  • Coordinated changes across packages in one PR
  • Single dependency graph; consistent versions
  • Single CI pipeline
  • Easier onboarding (one repo to clone)

Why not

  • Build tooling complexity
  • CI takes longer; without smart caching, untenable
  • Permission boundaries — how to lock down sensitive packages
  • Repo size grows; clones become slow
  • Teams can step on each other

The 2026 stack

pnpm workspaces

Package manager. Faster than npm/yarn, content-addressable storage, hoists less aggressively. The default for new monorepos.

Turborepo

Task runner. Caches build/test outputs. Skips rebuilding what hasn’t changed. Backed by Vercel.

Nx

More featureful than Turborepo: code generators, plugins for popular frameworks, dependency graph visualization. More opinionated; some teams find it heavyweight.

Yarn Berry / npm workspaces

Alternatives. Yarn Berry has Plug’n’Play (no node_modules) which can speed installs but breaks some tools. npm workspaces are simple but lack Turborepo-style task caching.

Project structure

Common layout:

monorepo/
  apps/
    web/
    mobile-web/
    admin/
  packages/
    ui/
    utils/
    api-client/
    config/

apps are deployable. packages are libraries used by apps and other packages.

Internal package versioning

Two main approaches:

  • Synchronized versions: all internal packages move together. Simpler.
  • Independent versioning: changesets tool, each package versions independently. More complex; required for libraries published outside the monorepo.

CI strategies

Without smart CI, every change tests every package. With Turborepo or Nx:

  1. Detect which files changed
  2. Compute affected packages (and their dependents)
  3. Run tests/build only for affected
  4. Cache results for unchanged

The result: 5–10x faster CI on typical PRs.

Remote caching

Turborepo and Nx both support remote caching — share build artifacts across team members and CI. If someone built X yesterday, you do not build X today.

Massive productivity gain for shared codebases.

Type sharing

One of the strongest monorepo benefits. Define types once in packages/types; consume in apps and other packages. Type changes are caught at the build step.

UI library in monorepo

Pattern: packages/ui contains components. Apps import:

import { Button } from '@your-org/ui';

Storybook lives in packages/ui; apps embed storybook stories during development.

Common pitfalls

  • Building everything from scratch — without smart caching, monorepos kill velocity
  • Mixing app and library boundaries — make the rule explicit
  • Letting any package depend on any other — creates tangled dependency graphs
  • Premature monorepo migration — for small teams, the complexity is not worth it

When to adopt

Worth it when:

  • 3+ deployable apps
  • Several shared packages
  • Teams collaborating across the codebase

Skip when:

  • Single app with internal-only utility libraries
  • Team smaller than 10 engineers

Frequently Asked Questions

Turborepo or Nx?

Turborepo for simpler setups; integrates naturally with existing tooling. Nx for more opinionated, code-gen-heavy stacks. Both ship in production.

Should mobile and web share a monorepo?

Sometimes — when there is a shared business logic layer or React Native app. But mobile build tooling can be heavy, and monorepo conflicts with mobile-native build systems.

How do I migrate from polyrepo to monorepo?

Incrementally. Start with one app + one shared package. Add packages one at a time. Use git-subtree or similar to preserve history if it matters.

Scroll to Top