An open-source build system and monorepo toolkit that amplifies developer productivity — supporting Angular, React, Node.js, and more.
Nx 20+Open SourceMonorepoCI/CD
Published: Jan 2019 Updated: Apr 2026
What is Nx?
Nx (formerly Nrwl Extension) is a powerful open-source build system and monorepo platform created by the team at Nrwl. Originally focused on Angular, it has grown into a full-stack toolkit supporting React, Vue, Node.js, Next.js, Nest.js, and more.
With Nx 20 (released 2024), the @nrwl scoped packages have been fully replaced by @nx scoped packages. Nx is no longer just an Angular CLI extension — it is a complete monorepo platform with smart caching, CI distribution, and AI-assisted development.
Monorepo vs Polyrepo
Monorepo (Nx approach)
All projects in one repository
Shared code without npm publishing
Atomic commits across projects
Consistent tooling and standards
Affected-only builds & tests
Single version of dependencies
Polyrepo (traditional)
Each project in its own repo
Shared code requires npm packages
Cross-repo changes are complex
Tooling varies per team
Always rebuild everything
Dependency version drift
Key Features (2024/2025)
Smart Caching
Local and remote caching via Nx Cloud — never rebuild what hasn't changed.
Nx Agents
Distribute CI tasks across multiple machines automatically with a single line of config.
Atomizer
Automatically splits long e2e tests into smaller parallel tasks for faster CI.
Dep Graph
Visualize project dependencies and understand what's affected by any change.
Project Crystal
Plugins enhance your existing config files without replacing them — no lock-in.
Flakiness Detection
Nx Cloud automatically retries flaky tests so your pipeline keeps moving.
Why Use Nx?
Share code across multiple apps in a single repository without duplication.
Run only the tasks affected by your changes — not the entire codebase.
Consistent tooling across Angular, React, Node.js, and more in one workspace.
Enforce module boundaries and architectural rules with lint rules.
Scale CI pipelines with distributed task execution via Nx Cloud.
nx g @nx/angular:application myapp
nx g @nx/angular:library mylib
nx g @nx/react:application my-react-app
nx g @nx/node:application my-api
Common Nx Commands
Terminal
nx serve myapp # Serve an app
nx build myapp # Build an app
nx test myapp # Run tests
nx lint myapp # Lint a project
nx affected --target=build # Build only affected projects
nx affected --target=test # Test only affected projects
nx graph # Open dependency graph in browser
nx migrate latest # Migrate to latest Nx version
nx show projects # List all projects
nx run-many --target=build # Run build for all projects
Enable Nx Cloud (Remote Caching)
Terminal
npx nx connect # Connect to Nx Cloud
npx nx-cloud start-ci-run --distribute-on="3 linux-medium-js" # Nx Agents in CI
Affected Commands — Run Only What Changed
Nx analyzes your git history and dependency graph to determine which projects are affected by your changes. This is one of Nx's most powerful features for large monorepos.
Terminal
nx affected --target=build # Build affected projects
nx affected --target=test # Test affected projects
nx affected --target=lint # Lint affected projects
nx affected --target=build --base=main # Compare against main branch
nx affected --target=build --base=HEAD~1 # Compare against last commit
nx affected:graph # Visualize affected projects
nx affected --target=build --parallel=3 # Run 3 builds in parallel
How it works: Nx compares your current branch against the base branch (default: main), finds changed files, then traverses the dependency graph to find all projects that depend on those files — directly or transitively.
Nx Caching Explained
Local Cache
Stored in .nx/cache on your machine. If you run the same task with the same inputs, Nx replays the cached output instantly — no re-execution.
Remote Cache (Nx Cloud)
Cache is shared across your entire team and CI. If a colleague already built a project, you get their cached result — zero rebuild time.
Nx uses ESLint rules to enforce architectural boundaries between libraries. You tag libraries and define which tags can depend on which — preventing spaghetti dependencies.
Tag libraries in their project.json: "tags": ["type:ui", "scope:shared"]. Running nx lint will then catch any boundary violations.
Nx vs Angular CLI
Feature
Angular CLI
Nx
Multiple apps in one repo
Smart build caching
Affected commands
Dependency graph
CI distribution (Nx Agents)
Multi-framework support
Module boundary enforcement
Code generators
Remote caching (Nx Cloud)
Task pipeline configuration
Top 20 Nx Interview Q&A
Commonly asked Nx and monorepo questions — click to reveal answers.
Q1
What is Nx and what problem does it solve?
ANS
Nx is an open-source build system and monorepo platform. It solves the problem of managing multiple related projects (apps and libraries) in a single repository by providing smart caching, affected-only task execution, dependency graph visualization, and consistent tooling across frameworks.
Q2
What is the difference between an app and a lib in Nx?
ANS
Apps are deployable units — they produce a runnable artifact (web app, API, mobile app). They should be thin and delegate logic to libraries. Libs are reusable units of code shared across apps. Most of your business logic, UI components, and services should live in libraries.
Q3
What is the Nx dependency graph?
ANS
The dependency graph (run with nx graph) is a visual representation of all projects in your workspace and their dependencies. Nx uses it to determine which projects are affected by a change and to optimize task execution order.
Q4
What are Nx affected commands and how do they work?
ANS
Affected commands (nx affected --target=build) compare your current branch against a base branch, find changed files, then traverse the dependency graph to identify all projects that depend on those files — directly or transitively. Only those projects are built/tested.
Q5
What is Nx caching and what are its two types?
ANS
Nx caching stores the output of tasks (build artifacts, test results) keyed by a hash of inputs. Local cache is stored in .nx/cache on your machine. Remote cache (via Nx Cloud) is shared across your team and CI — if anyone has already run a task with the same inputs, everyone gets the cached result.
Q6
What is the difference between nx.json and project.json?
ANS
nx.json is the workspace-level configuration — it defines default targets, caching rules, plugins, and named inputs that apply to all projects. project.json is project-level configuration — it defines the specific targets (build, serve, test) and their executors for one project.
Q7
What are Nx Generators?
ANS
Generators are code scaffolding tools run with nx g. They create apps, libraries, components, services, and more. They are equivalent to Angular CLI schematics. You can also create custom workspace generators to enforce your team's conventions.
Q8
What are Nx Executors?
ANS
Executors are the tasks that run when you call nx build, nx serve, nx test, etc. They are equivalent to Angular CLI builders. Defined in project.json under targets.
Q9
What is @nx/enforce-module-boundaries?
ANS
An ESLint rule that enforces architectural constraints between libraries. You tag libraries (e.g., type:ui, scope:shared) and define which tags can depend on which. This prevents circular dependencies and enforces clean architecture.
Q10
What is Nx Cloud?
ANS
Nx Cloud is a hosted service that provides remote caching and distributed task execution (Nx Agents). It allows your entire team and CI pipelines to share build/test caches, dramatically reducing CI times. It has a free tier for open-source projects.
Q11
What are Nx Agents?
ANS
Nx Agents distribute CI tasks across multiple machines automatically. You add a single line to your CI config (--distribute-on="3 linux-medium-js") and Nx Cloud provisions agents, distributes tasks optimally, and collects results.
Q12
What is the difference between nx run-many and nx affected?
ANS
nx run-many --target=build runs a target for ALL projects (or a specified list). nx affected --target=build runs a target only for projects affected by recent changes. Use affected in CI for speed.
Q13
What is Project Crystal in Nx?
ANS
Project Crystal (introduced in Nx 18) allows Nx plugins to infer project configuration from existing config files (like vite.config.ts, jest.config.ts) without requiring a project.json. This reduces Nx-specific config and avoids vendor lock-in.
Q14
How do you migrate to a newer version of Nx?
ANS
Run nx migrate latest to update package.json with the latest versions. Then run npm install to install them. Finally run nx migrate --run-migrations to apply any automated code migrations.
Q15
What is the difference between @nrwl and @nx packages?
ANS
Starting with Nx 16, Nrwl began migrating all packages from the @nrwl scope to the @nx scope. By Nx 20, the migration was complete. You should use @nx/angular, @nx/react, etc. instead of the old @nrwl/* packages.
Q16
What is a task pipeline in Nx?
ANS
A task pipeline defines the order in which tasks must run. For example, build depends on ^build (the ^ means dependencies first). Configured in nx.json under targetDefaults.build.dependsOn. Nx uses this to build projects in the correct order automatically.
Q17
What is the Nx Console?
ANS
Nx Console is a VS Code extension that provides a GUI for running Nx commands, generating code, and viewing the dependency graph. It makes Nx accessible without memorizing CLI commands and shows available generators and their options interactively.
Q18
How does Nx handle shared libraries between Angular and React apps?
ANS
Nx supports framework-agnostic utility and data-access libraries that can be shared between Angular and React apps. These libraries contain pure TypeScript (no framework-specific code). Framework-specific UI libraries are kept separate and tagged accordingly.
Q19
What is nx reset and when should you use it?
ANS
nx reset clears the local Nx cache and resets the daemon. Use it when you suspect stale cache is causing incorrect task results, after major config changes, or when troubleshooting unexpected build behavior.
Q20
What is the Nx daemon?
ANS
The Nx daemon is a background process that keeps the project graph in memory for faster task execution. It starts automatically when you run Nx commands. It significantly speeds up repeated commands in large workspaces by avoiding re-parsing the entire workspace on each run.
Q21
What is the Nx task pipeline and how do you configure it?
ANS
The task pipeline defines execution order between targets. Configured in nx.json under targetDefaults. The ^ prefix means "dependencies first". Example: "build": { "dependsOn": ["^build"] } ensures all library dependencies are built before the app that uses them.
Q22
What is the difference between nx run-many and nx affected?
ANS
nx run-many --target=build runs a target for ALL projects (or a specified list) regardless of changes. nx affected --target=build runs a target only for projects affected by recent git changes. Use affected in CI for speed, run-many for full releases.
Q23
How do you create a custom Nx generator?
ANS
Run nx g @nx/plugin:generator my-generator --project=tools to scaffold a generator. Generators use the @nx/devkit API to read/write files, update JSON configs, and run other generators. They are ideal for enforcing team conventions when creating new libraries or components.
Q24
What is Nx Atomizer and how does it speed up CI?
ANS
Nx Atomizer (available via Nx Cloud) automatically splits large test suites (e2e, unit) into smaller atomic tasks that run in parallel across Nx Agents. Instead of one long test run, Nx distributes individual test files across multiple machines — dramatically reducing total CI time without any manual configuration.
Q25
What is the Nx Console VS Code extension?
ANS
Nx Console is an official VS Code extension that provides a GUI for all Nx operations. It lets you run generators interactively (with form fields for options), execute targets, view the dependency graph, and see all available commands — without memorizing CLI syntax. Install it from the VS Code marketplace: nrwl.angular-console.