This is a short list of Nx-specific terms that will help you understand the rest of the documentation.
Application
Section titled “Application”A project that can run on its own. Generally uses libraries.
Atomizer
Section titled “Atomizer”The Atomizer is an Nx Cloud feature that automatically splits tasks so that they can be executed in parallel.
Atomizer automatically splits tasks on Nx Agents, providing you detailed task information in the UI, including interpreted logs and artifacts, automatically grouped by project and workflow.
Buildable Library
Section titled “Buildable Library”A library that has a build target. Some libraries can be generated with a build target using the --buildable flag.
A mechanism for saving the output of a calculation so it can be replayed later without actually performing the calculation again.
See: Cache Task Results
Cache Hit
Section titled “Cache Hit”When the cache inputs for a task match an existing entry in the cache and the cache outputs can be replayed without actually running the task.
See: Cache Task Results
Cache Inputs
Section titled “Cache Inputs”Everything that might change the output of a task. This may include source code, task options, environment variables and other settings determined at run time. These values are combined as a hash to serve as a key for an entry in the cache.
Cache Miss
Section titled “Cache Miss”When the cache inputs for a task do not match an existing entry in the cache and the task needs to be executed.
See: Cache Task Results
Cache Outputs
Section titled “Cache Outputs”The terminal output and any file artifacts created by running a task. These values are stored in the cache to be replayed later.
See: Outputs Reference
CIPE (Continuous Integration Pipeline Execution)
Section titled “CIPE (Continuous Integration Pipeline Execution)”CI Pipeline Executions are a grouping mechanism for all Nx and Nx Cloud actions that occur within a single continuous integration pipeline. The Nx Cloud task runner automatically detects when it is running in a CI environment, so this grouping is done automatically. In almost all cases, this detection will be a 1:1 match with your CI provider's concept of a "pipeline" or "workflow".
Command
Section titled “Command”Anything you run in the terminal. An example command that invokes a task is nx build my-app.
See: Run Tasks
Configurations
Section titled “Configurations”A set of preconfigured options for a target that should be enabled altogether. For example, a production configuration would set all the options needed for a build that could be deployed to production.
Distributed Task Execution
Section titled “Distributed Task Execution”A system for running tasks in CI across multiple agent processes across many machines. Nx Agents enables distributed task execution on agent machines that are managed by Nx.
Executor
Section titled “Executor”A script that performs some action on your code. This can include building, linting, testing, serving and many other actions. A target configuration specifies an executor and a set of options. Executors can be found in plugins.
Flaky Tasks
Section titled “Flaky Tasks”Tasks that will sometimes succeed and sometimes fail without any change to the inputs. These tasks are often e2e tests and are particularly problematic in CI. Nx Cloud automatically detects flaky tasks and re-runs them.
Generator
Section titled “Generator”A script that creates or modifies your code. Generators can be found in plugins.
See: Use Code Generators
A computer science concept that consists of nodes connected by edges. In the Nx context, there are two graphs: the project graph which describes dependencies between projects and the task graph which describes dependencies between tasks.
See: Explore the Graph
Launch Template
Section titled “Launch Template”Launch Templates are used to set up an agent machine. They specify a resource class, an image and a series of set up steps before tasks are executed on that machine.
See: Launch Templates
Library
Section titled “Library”A project that is used by applications or other libraries.
Monolith
Section titled “Monolith”A large application that is difficult to separate into smaller pieces.
Monorepo
Section titled “Monorepo”A repository with multiple projects.
See: monorepo.tools
Nested Project
Section titled “Nested Project”A project that is located in a sub-folder of another project. This was made possible in Nx 15.3.
Nx Agents
Section titled “Nx Agents”A paid service that hosts and manages customizable worker machines to run parts of your CI pipeline faster and cheaper than a traditional CI provider. When possible, Nx Agents uses distributed task execution to optimize your pipeline.
Nx Cloud
Section titled “Nx Cloud”The umbrella term for all CI-related products that Nx provides.
See: CI with Nx
Nx Replay
Section titled “Nx Replay”Nx Replay is the product offered by Nx Cloud that enables remote caching.
See: Use Remote Caching
Package
Section titled “Package”A project. It is sometimes published as an npm package.
Plugin
Section titled “Plugin”A set of executors, generators and other code that extends the functionality of Nx. May be installed from a package manager like NPM or developed directly in the repository.
Polyrepo
Section titled “Polyrepo”Related projects spread across multiple repositories.
Project
Section titled “Project”The unit of code on which a task can be run. A project can be an application or a library.
Publishable Library
Section titled “Publishable Library”A library that has a publish target. Some libraries can be generated with a publish target using the --publishable flag.
Remote Cache
Section titled “Remote Cache”A cache that can be shared between all developers using the repo and the CI system. This product is called Nx Replay.
See: Share Your Cache
Root-Level Project
Section titled “Root-Level Project”A project that has its own root folder at the root of the repository. Every other project in the repo is a nested project.
Runs in Nx Cloud are Nx commands that result in some number of Tasks being performed.
nx run my-app:buildis a run that performs a single tasknx run-many -t test,buildis a run that performs many tasks.nx affected -t test,buildis a run that performs zero to many tasks.
When a run exists in a CI environment, Nx Cloud will automatically associate it with the appropriate Run Group and CI Pipeline Execution
Run Group
Section titled “Run Group”Run groups are a more specific grouping mechanism for Nx and Nx Cloud actions, and exist as children within a single CI Pipeline Execution. Typically, run groups are used when there are different hardware requirements (ex: a Linux run group, and a MacOS run group) for the different commands.
When using Distributed Task Execution, Nx Agents can only belong to a single run group. This means each additional run group requires its own pool of agents.
Standalone Repository
Section titled “Standalone Repository”A repository with a single application at the root level. This set up is made possible in Nx 15.3.
Target
Section titled “Target”The name of an action taken on a project.
See: Run Tasks
An invocation of a target on a specific project.
See: Run Tasks
Task Pipeline
Section titled “Task Pipeline”The set of dependencies between tasks that ensure that tasks are run in the correct order.
Workspace
Section titled “Workspace”A git repository. An Nx workspace is a git repository using Nx.