This PR removes the `/nx-api` pages from `nx-dev`. They are already redirected from `/nx-api` to either `/technologies` or `/reference/core-api` URLs. e.g. `/nx-api/nx` goes to `/reference/core-api/nx` and `/nx-api/react` goes to `/technologies/react/api` **Changes**: - Remove old `nx-api.json` from being generated in `scripts/documentation/generators/generate-manifests.ts` -- this was used to generate the sitemap - Remove `pages/nx-api` from Next.js app since we don't need them - Remove workaround from link checker `scripts/documentation/internal-link-checker.ts` -- the angular rspack/rsbuild and other workarounds are gone now that they are proper docs in `map.json` - Update Powerpack/Remote Cache reference docs to exclude API documents (since they are duplicated in the Intro page) -- `nx-dev/models-document/src/lib/mappings.ts` - All content in `docs` have been updated with new URL structure **Note:** Redirects are already handled, and Claude Code was used to verify the updated `docs/` URLs (see report below). The twelve 404s links were updated by hand. ## Verification Report https://gist.github.com/jaysoo/c7863fe7e091cb77929d1976165c357a
4.9 KiB
| title | description |
|---|---|
| Executors and Configurations | Learn about Nx executors, pre-packaged node scripts that run tasks consistently across projects, and how to configure them in project.json files. |
Executors and Configurations
Executors are pre-packaged node scripts that can be used to run tasks in a consistent way.
In order to use an executor, you need to install the plugin that contains the executor and then configure the executor in the project's project.json file.
{
"root": "apps/cart",
"sourceRoot": "apps/cart/src",
"projectType": "application",
"generators": {},
"targets": {
"build": {
"executor": "@nx/webpack:webpack",
"options": {
"outputPath": "dist/apps/cart",
...
}
},
"test": {
"executor": "@nx/jest:jest",
"options": {
...
}
}
}
}
Each project has targets configured to run an executor with a specific set of options. In this snippet, cart has two targets defined - build and test.
Each executor definition has an executor property and, optionally, an options and a configurations property.
executoris a string of the form[package name]:[executor name]. For thebuildexecutor, the package name is@nx/webpackand the executor name iswebpack.optionsis an object that contains any configuration defaults for the executor. These options vary from executor to executor.configurationsallows you to create presets of options for different scenarios. All the configurations start with the properties defined inoptionsas a baseline and then overwrite those options. In the example, there is aproductionconfiguration that overrides the default options to setsourceMaptofalse.
Once configured, you can run an executor the same way you would run any target:
nx [command] [project]
nx build cart
Browse the executors that are available in the plugin registry.
Run a Terminal Command from an Executor
If defining a new target that needs to run a single shell command, there is a shorthand for the nx:run-commands executor that can be used.
{
"root": "apps/cart",
"sourceRoot": "apps/cart/src",
"projectType": "application",
"generators": {},
"targets": {
"echo": {
"command": "echo 'hello world'"
}
}
}
For more info, see the run-commands documentation
Build your own Executor
Nx comes with a Devkit that allows you to build your own executor to automate your Nx workspace. Learn more about it in the docs page about creating a local executor.
Running executors with a configuration
You can use a specific configuration preset like this:
nx [command] [project] --configuration=[configuration]
nx build cart --configuration=production
Use Task Configurations
The configurations property provides extra sets of values that will be merged into the options map.
{
"build": {
"executor": "@nx/js:tsc",
"outputs": ["{workspaceRoot}/dist/libs/mylib"],
"dependsOn": ["^build"],
"options": {
"tsConfig": "libs/mylib/tsconfig.lib.json",
"main": "libs/mylib/src/main.ts"
},
"configurations": {
"production": {
"tsConfig": "libs/mylib/tsconfig-prod.lib.json"
}
}
}
}
You can select a configuration like this: nx build mylib --configuration=production
or nx run mylib:build:production.
The following code snippet shows how the executor options get constructed:
require(`@nx/jest`).executors['jest']({
...options,
...selectedConfiguration,
...commandLineArgs,
}); // Pseudocode
The selected configuration adds/overrides the default options, and the provided command line args add/override the configuration options.
Default Configuration
When using multiple configurations for a given target, it's helpful to provide a default configuration.
For example, running e2e tests for multiple environments. By default it would make sense to use a dev configuration for day to day work, but having the ability to run against an internal staging environment for the QA team.
{
"e2e": {
"executor": "@nx/cypress:cypress",
"options": {
"cypressConfig": "apps/my-app-e2e/cypress.config.ts"
},
"configurations": {
"dev": {
"devServerTarget": "my-app:serve"
},
"qa": {
"baseUrl": "https://some-internal-url.example.com"
}
},
"defaultConfiguration": "dev"
}
}
When running nx e2e my-app-e2e, the dev configuration will be used. In this case using the local dev server for my-app.
You can always run the other configurations by explicitly providing the configuration i.e. nx e2e my-app-e2e --configuration=qa or nx run my-app-e2e:e2e:qa