Monorepo Vocabulary: Nx, Turborepo, and Modern Workspace Terms
Learn monorepo vocabulary for modern teams — workspace, task pipelines, remote cache, affected commands, module federation, changesets, and Nx vs Turborepo trade-offs.
Many fast-growing engineering teams are consolidating their codebases into a single repository — a monorepo. Tools like Nx, Turborepo, and Bazel have made this practical at scale by solving the key challenges: build speed, dependency management, and affected-change detection. If your team is migrating to a monorepo, or you have just joined one, this vocabulary guide will get you up to speed quickly.
Monorepo vs Polyrepo
Monorepo
A monorepo (short for monolithic repository) is a single version-control repository that contains multiple projects, packages, or applications. All teams commit to the same repo.
“We moved from 12 separate repos to a monorepo. Now when a shared library changes, we can see exactly which apps are affected in one pull request.”
Polyrepo
A polyrepo (or multirepo) is the traditional approach where each project or service has its own repository.
| Monorepo advantages | Polyrepo advantages |
|---|---|
| Atomic cross-project changes | Smaller, focused repos per team |
| Shared tooling and conventions | Independent release cycles |
| Easier code sharing | Simpler permissions model |
| Single source of truth for dependencies | Less accidental coupling |
“We chose monorepo over polyrepo because we have a shared design system that changes frequently — atomic commits across the app and the library are much cleaner.”
Workspace Concepts
Workspace
In a monorepo context, a workspace refers to the overall repository configuration that ties all packages together. Both npm and Yarn have a workspaces field in package.json; Nx and Turborepo build on top of this.
“Run
npm installat the workspace root — hoisting handles the shared dependencies for all packages.”
Package / Project
A package (in npm workspace terminology) or project (in Nx terminology) is a single unit within the monorepo — an application, a library, or a tool. Each usually has its own package.json and tsconfig.json.
“We have 8 projects in the monorepo: 3 apps (
web,mobile,admin) and 5 shared libraries.”
Shared Library vs App
A shared library is a package that other packages depend on — a UI component library, a utility package, an API client. An app is a deployable artefact — a Next.js site, a NestJS service, a mobile app.
“The
@acme/uishared library is used by both thewebandadminapps. Changes to it affect both.”
Build Systems
Nx
Nx is a powerful monorepo build system and set of developer tools with deep integration for TypeScript, React, Angular, NestJS, and more. It provides code generation, task orchestration, dependency graph visualisation, and remote caching.
“We use Nx because of the project graph — it shows exactly which projects depend on what, and
nx affectedonly runs tasks for what actually changed.”
Turborepo
Turborepo is a high-performance task runner for JavaScript/TypeScript monorepos. It focuses on fast builds through caching and parallelism. Lighter and simpler than Nx but with fewer built-in integrations.
“Turborepo was easy to adopt — we just added a
turbo.jsonto our existing workspace and build times dropped by 70%.”
Bazel
Bazel is a build system originally developed at Google. It supports any language and is used in very large monorepos. More complex to configure than Nx or Turborepo.
Task Orchestration
Task Pipeline
A task pipeline defines the order in which tasks run across packages and declares dependencies between them. For example, you might say “before building an app, build all its library dependencies first.”
“We defined a pipeline where
builddepends on^build— Turborepo builds all upstream packages before the current one.”
Remote Cache
The remote cache stores the output of tasks (built files, test results) on a shared server. When the same task runs again with the same inputs, the output is downloaded from the cache instead of recomputed.
“With remote cache enabled, CI went from 12 minutes to 2 minutes — every package that didn’t change was just downloaded from the cache.”
Affected Commands
Affected commands run tasks only for packages that have actually changed since a base commit (usually the main branch). This is one of the core speed benefits of a monorepo build system.
“Run
nx affected --target=testto only test the packages touched by this PR. No need to run tests for packages that didn’t change.”
Dependency Graph
The dependency graph (or project graph) maps which packages depend on which other packages. Build systems use it to determine build order and calculate the affected set.
“Open the Nx project graph to see which apps will be affected if we change
@acme/api-client.”
Advanced Patterns
Module Federation
Module federation is a Webpack and Vite feature that lets separately deployed applications share code at runtime. In a monorepo, it enables a micro-frontend architecture where each team deploys independently.
“We use module federation so the
checkoutmicro-frontend can be deployed without redeploying theshellapp.”
Changesets
Changesets is a tool for managing versioning and changelogs in monorepos with publishable packages. When you make a change, you add a changeset — a markdown file describing the change and whether it is a patch, minor, or major update.
“Every PR that changes a public package must include a changeset file. The CI pipeline reads them and bumps versions automatically.”
Publish Workflow
The publish workflow is the automated process that reads changeset files, bumps package versions, updates changelogs, and publishes to npm. Typically runs on merge to main.
“The publish workflow runs on every merge. It bumps the version, tags the commit, and publishes the updated packages to the npm registry.”
Common Monorepo Phrases
| Phrase | Meaning |
|---|---|
| ”Run affected only” | Only execute tasks for changed packages |
| ”The graph shows it’s downstream” | Other packages depend on this one — a change here cascades |
| ”Cache hit rate is low” | Tasks are not being served from cache — investigate input changes |
| ”We need to hoist this dependency” | Move it to the root package.json so all packages share the same version |
| ”Add a changeset” | Create a changeset file describing what changed and the semver bump |
| ”This is an internal library” | It’s not published to npm — only used within the monorepo |
| ”The pipeline is blocking” | A required task must complete before downstream tasks can start |