English for Nx Monorepo Developers

Nx monorepos introduce a vocabulary built around dependency graphs and computation caching that doesn’t exist in single-package repos. Teams that can’t distinguish “affected” from “all,” or a “project boundary” from a folder structure, tend to write imprecise CI reports and vague code review comments. This guide covers the terms you need to discuss an Nx workspace clearly.

Key Vocabulary

Project graph — the dependency graph Nx builds by analyzing imports across the workspace, used to determine which projects depend on which. “The project graph shows that the checkout app depends on the shared UI library, so a change there should trigger checkout’s tests too.”

Affected — the set of projects whose code has changed, directly or transitively, since a given git reference, used to scope CI to only what needs rebuilding. “Instead of running the whole test suite, CI only runs tests for affected projects, which cuts our pipeline time from twenty minutes to four.”

Task graph — the ordered set of tasks (build, test, lint) Nx computes across affected projects, respecting dependencies so a library builds before the app that consumes it. “Nx generates the task graph automatically, so we don’t have to manually specify that the shared library must build before the app.”

Computation caching — Nx’s mechanism for skipping a task entirely and replaying its cached output if the inputs haven’t changed since the last run. “That build finished in two seconds because of computation caching — nothing in its inputs changed since the last CI run.”

Module boundary — a lint rule (@nx/enforce-module-boundaries) that restricts which projects can import from which, preventing an app from reaching into another app’s internals. “The module boundary rule is blocking this import because feature libraries aren’t allowed to depend directly on other features.”

Nx Cloud — a hosted service that shares the computation cache and distributes task execution across CI machines and developer laptops. “With Nx Cloud, if a teammate already built this exact commit, your local build just pulls the cached result instead of rebuilding.”

Common Phrases

• “Is this project actually affected by the change, or is the graph over-reporting?”
• “Did we hit the cache here, or is this a cold build?”
• “That import violates the module boundary — feature libraries shouldn’t reach into other features directly.”
• “Let’s check the task graph before assuming this needs a full rebuild.”
• “Is Nx Cloud distributing this task, or is it running locally?”

Example Sentences

Explaining a CI speedup in a retro: “We enabled nx affected in the pipeline, so a change to a single library no longer triggers a full rebuild of every app — only the projects that actually depend on it run.”

Reporting a boundary violation: “The lint step is failing because the payments feature is importing directly from the checkout feature, which violates our module boundary rules — it should go through the shared domain library instead.”

Discussing caching behavior with a teammate: “The build looked instant in CI because of computation caching — the inputs, including the lockfile hash, hadn’t changed since the last successful run on that branch.”

Professional Tips

• Say “affected projects” specifically, not “changed files,” when discussing what CI will rebuild — the two aren’t the same once you account for the dependency graph.
• When debugging a slow pipeline, ask whether it’s a cache miss or a genuinely larger task graph — they require different fixes.
• Use “module boundary” rather than “import rule” in code review — it signals the architectural intent, not just a lint warning.
• Clarify whether caching is local or via Nx Cloud when explaining why a build was fast on one machine but not another.

Practice Exercise

1. Explain in two sentences why nx affected can make CI faster without sacrificing correctness.
2. Write a one-sentence code review comment flagging a module boundary violation.
3. Describe, in your own words, the difference between the project graph and the task graph.