Use the project graph, nx affected for CI optimisation, computation caching, generators vs executors, and module boundary enforcement.
0 / 5 completed
1 / 5
What is the Nx project graph and what does it track?
Project graph:nx graph visualises the graph in a browser. When a file changes, Nx traverses the graph upward to find all projects that depend (directly or transitively) on the changed project. This enables the nx affected commands to rebuild and retest only what could have been broken, dramatically reducing CI time in large monorepos.
2 / 5
What does nx affected determine and how does it identify affected projects?
nx affected:nx affected -t test runs tests only for affected projects. nx affected -t build,lint,test runs all three targets. The base is configurable: --base=HEAD~1 compares against one commit. In CI, compare against the merge base: --base=origin/main. This can reduce a 60-minute full CI run to 5 minutes for a small change.
3 / 5
What is Nx computation caching and how does it avoid redundant work?
Computation caching: the cache key includes source files, package.json versions, environment variables, and the task command. If the key matches a previous run, Nx prints the cached output and returns instantly. Nx Cloud extends this to a distributed remote cache — one developer's build is cached for all team members and CI pipelines.
4 / 5
What are Nx generators and how do they differ from Nx executors?
Generators vs executors: generators are one-time scaffold operations (create a library, add a feature, migrate a pattern). Executors are repeatable task runners registered in project.json as targets. Custom generators enforce team conventions; custom executors wrap non-standard build tools. Both are written as Node.js modules in the tools/ directory or workspace plugins.
5 / 5
What are Nx module boundary rules and how are they enforced?
Module boundaries: tag projects with "tags": ["scope:shared", "type:util"] in project.json. Configure rules: { "sourceTag": "scope:feature", "onlyDependOnLibsWithTags": ["scope:shared", "scope:data"] }. The ESLint rule runs in CI to catch violations. This enforces architectural boundaries that prevent the "big ball of mud" pattern in large monorepos.