miel.truyen/nx
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs(core): configuration guide updates (#6193)

Browse Source
This commit is contained in:
Brandon 2021-06-30 10:05:20 -05:00 committed by GitHub
parent 17bc2cf382
commit 603d62d911
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 73 additions and 73 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
docs/angular/guides/configuration.md
View File

@ -1,6 +1,6 @@
# Configuration # Configuration
There are three top-level configuration files every Nx workspace has: `angular.json`, `nx.json`, and `tsconfig.base.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. There are three top-level configuration files every Nx workspace has: `angular.json`, `nx.json`, and `tsconfig.base.json`. Many Nx plugins modify these files when generating new code, but you can also modify them manually.
## angular.json ## angular.json
@ -89,12 +89,12 @@ For instance, the following configures `mylib`.
- `root` tells Nx the location of the library including its sources and configuration files. - `root` tells Nx the location of the library including its sources and configuration files.
- `sourceRoot` tells Nx the location of the library's source files. - `sourceRoot` tells Nx the location of the library's source files.
- `projectType` is either 'application' or 'library'. - `projectType` is either 'application' or 'library'. The project type is used in dep graph viz and in a few aux commands.
- `architect` configures all the targets which define what tasks you can run against the library. - `architect` configures all the targets which define what tasks you can run against the library.
> Nx uses the architect library built by the Angular team at Google. The naming reflects that. Important to note: it's a general purpose library that **does not** have any dependency on Angular. > Nx uses the architect library built by the Angular team at Google. The naming reflects that. Important to note: it's a general purpose library that **does not** have any dependency on Angular.
> Projects utilizing `project.json` files will not be present in `angular.json`. > Projects utilizing `project.json` files are not present in `angular.json`.
### Targets ### Targets
@ -133,7 +133,7 @@ The `options` provides a map of values that will be passed to the builder. The p
**Outputs** **Outputs**
The `outputs` property lists the folders the builder will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. The `outputs` property lists the folders the builder creates files in. The property is optional. If not provided, Nx assumes it is `dist/libs/mylib`.
```json ```json
{ {
@ -203,11 +203,11 @@ Targets can depend on other targets. A common scenario is having to build depend
} }
``` ```
In this case, running `nx build myapp` will build all the buildable libraries `myapp` depends on first. In other words, `nx build myapp` will result in multiple tasks executing. The `--parallel`, and `--max-parallel` flags will have the same effect as they would with `run-many` or `affected`. In this case, running `nx build myapp` builds all the buildable libraries `myapp` depends on first. In other words, `nx build myapp` results in multiple tasks executing. The `--parallel`, and `--max-parallel` flags have the same effect as they would with `run-many` or `affected`.
It is also possible to define dependencies between the targets of the same project. It is also possible to define dependencies between the targets of the same project.
In the following example invoking `nx build myapp` will build all the libraries first, then `nx build-base myapp` will be executed and only then `nx build myapp` will be executed. In the following example invoking `nx build myapp` builds all the libraries first, then `nx build-base myapp` is executed and only then `nx build myapp` is executed.
```json ```json
{ {
@ -242,7 +242,7 @@ Often the same `dependsOn` configuration has to be defined for every project in
### Generators ### Generators
Generators that are created using `@angular-devkit` are called schematics. You can configure default generator options in `angular.json` as well. For instance, the following will tell Nx to always pass `--style=scss` when creating new libraries. Generators that are created using `@angular-devkit` are called schematics. Default generator options are configured `angular.json` as well. For instance, the following will tell Nx to always pass `--style=scss` when creating new libraries.
```json ```json
{ {
@ -256,7 +256,7 @@ Generators that are created using `@angular-devkit` are called schematics. You c
### CLI Options ### CLI Options
The following command will generate a new library: `nx g @nrwl/angular:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. The following command generates a new library: `nx g @nrwl/angular:lib mylib`. After setting the `defaultCollection` property, the lib is generated without mentioning the collection name: `nx g lib mylib`.
```json ```json
{ {
@ -359,22 +359,22 @@ Tells Nx which branch and HEAD to use when calculating affected projects.
### Tasks Runner Options ### Tasks Runner Options
Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner named "default" is used by default. Specify a different one by passing `--runner`.
> A task is an invocation of a target. > A task is an invocation of a target.
Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. - `cacheableOperations` defines the list of targets/operations that are cached by Nx.
- `parallel` defines whether to run targets in parallel - `parallel` defines whether to run targets in parallel
- `maxParallel` defines the max number of processes used. - `maxParallel` defines the max number of processes used.
- `captureStderr` defines whether the cache will capture stderr or just stdout - `captureStderr` defines whether the cache captures stderr or just stdout
- `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false` - `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false`
- `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default. - `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default.
- `encryptionKey` (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner will normalize the key length, so any length of key is acceptable. - `encryptionKey` (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable.
- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. - `runtimeCacheInputs` defines the list of commands that are run by the runner to include into the computation hash value.
`runtimeCacheInputs` can be set as follows: `runtimeCacheInputs` are set as follows:
```json ```json
{ {
@ -432,12 +432,12 @@ Nx performs advanced source-code analysis to figure out the project graph of the
In the example above: In the example above:
- Changing `angular.json` will affect every project. - Changing `angular.json` affects every project.
- Changing the `dependencies` property in `package.json` will affect every project. - Changing the `dependencies` property in `package.json` affects every project.
- Changing the `devDependencies` property in `package.json` will only affect `mylib`. - Changing the `devDependencies` property in `package.json` only affects `mylib`.
- Changing any of the custom check `scripts` in `package.json` will affect every project. - Changing any of the custom check `scripts` in `package.json` affects every project.
- Changing `globalFile` will only affect `myapp`. - Changing `globalFile` only affects `myapp`.
- Changing any CSS file inside the `styles` directory will only affect `myapp`. - Changing any CSS file inside the `styles` directory only affects `myapp`.
You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well.
@ -486,5 +486,5 @@ The syntax is the same as a [`.gitignore` file](https://git-scm.com/book/en/v2/G
**When a file is specified in the `.nxignore` file:** **When a file is specified in the `.nxignore` file:**
1. Changes to that file will not be taken into account in the `affected` calculations. 1. Changes to that file are not taken into account in the `affected` calculations.
2. Even if the file is outside an app or library, `nx workspace-lint` will not warn about it. 2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it.

50
docs/node/guides/configuration.md
View File

@ -1,6 +1,6 @@
# Configuration # Configuration
There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.base.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.base.json`. Many Nx plugins modify these files when generating new code, but you can also modify them manually.
## workspace.json ## workspace.json
@ -108,7 +108,7 @@ For instance, the following configures `mylib`.
- `projectType` is either 'application' or 'library'. The project type is used in dep graph viz and in a few aux commands. - `projectType` is either 'application' or 'library'. The project type is used in dep graph viz and in a few aux commands.
- `targets` configures all the targets which define what tasks you can run against the library. - `targets` configures all the targets which define what tasks you can run against the library.
> Projects utilizing `project.json` files will not be present in `workspace.json`. > Projects utilizing `project.json` files are not present in `workspace.json`.
### Targets ### Targets
@ -127,7 +127,7 @@ Let's look at the simple target:
**Target Name** **Target Name**
The name of the target `test` means that you can invoke it as follows: `nx test mylib` or `nx run mylib:test`. The name isn't significant in any other way. If you rename it to, for example, `mytest`, you will be able to run as follows: `nx mytest mylib` or `nx run mylib:mytest`. The name of the target `test` means that you can invoke it as follows: `nx test mylib` or `nx run mylib:test`. The name isn't significant in any other way. If you rename it to, for example, `mytest`, you run as follows: `nx mytest mylib` or `nx run mylib:mytest`.
**Executor** **Executor**
@ -135,7 +135,7 @@ The `executor` property tells Nx what function to invoke when you run the target
**Options** **Options**
The `options` provides a map of values that will be passed to the executor. The provided command line args will be merged into this map. I.e., `nx test mylib --jestConfig=libs/mylib/another-jest.config.js` will pass the following to the executor: The `options` provides a map of values that are passed to the executor. The provided command line args are merged into this map. For example, `nx test mylib --jestConfig=libs/mylib/another-jest.config.js` passes the following to the executor:
```json ```json
{ {
@ -145,7 +145,7 @@ The `options` provides a map of values that will be passed to the executor. The
**Outputs** **Outputs**
The `outputs` property lists the folders the executor will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. The `outputs` property lists the folders the executor creates files in. The property is optional. If not provided, Nx assumes it is `dist/libs/mylib`.
```json ```json
{ {
@ -164,7 +164,7 @@ The `outputs` property lists the folders the executor will create files in. The
**Configurations** **Configurations**
The `configurations` property provides extra sets of values that will be merged into the options map. The `configurations` property provides extra sets of values that are merged into the options map.
```json ```json
{ {
@ -219,11 +219,11 @@ Targets can depend on other targets. A common scenario is having to build depend
} }
``` ```
In this case, running `nx build myapp` will build all the buildable libraries `myapp` depends on first. In other words, `nx build myapp` will result in multiple tasks executing. The `--parallel`, and `--max-parallel` flags will have the same effect as they would with `run-many` or `affected`. In this case, running `nx build myapp` builds all the buildable libraries `myapp` depends on first. In other words, `nx build myapp` results in multiple tasks executing. The `--parallel`, and `--max-parallel` flags have the same effect as they would with `run-many` or `affected`.
It is also possible to define dependencies between the targets of the same project. It is also possible to define dependencies between the targets of the same project.
In the following example invoking `nx build myapp` will build all the libraries first, then `nx build-base myapp` will be executed and only then `nx build myapp` will be executed. In the following example invoking `nx build myapp` builds all the libraries first, then `nx build-base myapp` is executed and only then `nx build myapp` is executed.
```json ```json
{ {
@ -258,7 +258,7 @@ Often the same `dependsOn` configuration has to be defined for every project in
### Generators ### Generators
You can configure default generator options in `workspace.json` as well. For instance, the following will tell Nx to always pass `--js` when creating new libraries. Default generator options are configured in `workspace.json` as well. For instance, the following tells Nx to always pass `--js` when creating new libraries.
```json ```json
{ {
@ -290,7 +290,7 @@ You can also do it on the project level:
### CLI Options ### CLI Options
The following command will generate a new library: `nx g @nrwl/node:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. The following command generates a new library: `nx g @nrwl/node:lib mylib`. After setting the `defaultCollection` property, the lib is generated without mentioning the collection name: `nx g lib mylib`.
```json ```json
{ {
@ -383,22 +383,22 @@ Tells Nx which branch and HEAD to use when calculating affected projects.
### Tasks Runner Options ### Tasks Runner Options
Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner named "default" is used by default. Specify a different one by passing `--runner`.
> A task is an invocation of a target. > A task is an invocation of a target.
Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. - `cacheableOperations` defines the list of targets/operations that are cached by Nx.
- `parallel` defines whether to run targets in parallel - `parallel` defines whether to run targets in parallel
- `maxParallel` defines the max number of processes used. - `maxParallel` defines the max number of processes used.
- `captureStderr` defines whether the cache will capture stderr or just stdout - `captureStderr` defines whether the cache captures stderr or just stdout
- `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false` - `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false`
- `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default. - `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default.
- `encryptionKey` (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner will normalize the key length, so any length of key is acceptable. - `encryptionKey` (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable.
- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. - `runtimeCacheInputs` defines the list of commands that are run by the runner to include into the computation hash value.
`runtimeCacheInputs` can be set as follows: `runtimeCacheInputs` are set as follows:
```json ```json
{ {
@ -441,12 +441,12 @@ Nx performs advanced source-code analysis to figure out the project graph of the
In the example above: In the example above:
- Changing `workspace.json` will affect every project. - Changing `workspace.json` affects every project.
- Changing the `dependencies` property in `package.json` will affect every project. - Changing the `dependencies` property in `package.json` affects every project.
- Changing the `devDependencies` property in `package.json` will only affect `mylib`. - Changing the `devDependencies` property in `package.json` only affects `mylib`.
- Changing any of the custom check `scripts` in `package.json` will affect every project. - Changing any of the custom check `scripts` in `package.json` affects every project.
- Changing `globalFile` will only affect `myapp`. - Changing `globalFile` only affects `myapp`.
- Changing any CSS file inside the `styles` directory will only affect `myapp`. - Changing any CSS file inside the `styles` directory only affects `myapp`.
You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well.
@ -464,7 +464,7 @@ You can also add dependencies between projects. For instance, the example below
} }
``` ```
> Projects utilizing `project.json` files will not be present in `nx.json`. > Projects utilizing `project.json` files are not present in `nx.json`.
### Target Dependencies ### Target Dependencies
@ -497,5 +497,5 @@ The syntax is the same as a [`.gitignore` file](https://git-scm.com/book/en/v2/G
**When a file is specified in the `.nxignore` file:** **When a file is specified in the `.nxignore` file:**
1. Changes to that file will not be taken into account in the `affected` calculations. 1. Changes to that file are not taken into account in the `affected` calculations.
2. Even if the file is outside an app or library, `nx workspace-lint` will not warn about it. 2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it.

52
docs/react/guides/configuration.md
View File

@ -1,6 +1,6 @@
# Configuration # Configuration
There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.base.json`. Many Nx plugins will modify these files when generating new code, but you can also modify them manually. There are three top-level configuration files every Nx workspace has: `workspace.json`, `nx.json`, and `tsconfig.base.json`. Many Nx plugins modify these files when generating new code, but you can also modify them manually.
## workspace.json ## workspace.json
@ -98,7 +98,7 @@ For instance, the following configures `mylib`.
- `projectType` is either 'application' or 'library'. The project type is used in dep graph viz and in a few aux commands. - `projectType` is either 'application' or 'library'. The project type is used in dep graph viz and in a few aux commands.
- `targets` configures all the targets which define what tasks you can run against the library. - `targets` configures all the targets which define what tasks you can run against the library.
> Projects utilizing `project.json` files will not be present in `workspace.json`. > Projects utilizing `project.json` files are not present in `workspace.json`.
### Targets ### Targets
@ -118,7 +118,7 @@ Let's look at the simple target:
**Target Name** **Target Name**
The name of the target `test` means that you can invoke it as follows: `nx test mylib` or `nx run mylib:test`. The name isn't significant in any other way. If you rename it to, for example, `mytest`, you will be able to run as follows: `nx mytest mylib` or `nx run mylib:mytest`. The name of the target `test` means that you can invoke it as follows: `nx test mylib` or `nx run mylib:test`. The name isn't significant in any other way. If you rename it to, for example, `mytest`, you run as follows: `nx mytest mylib` or `nx run mylib:mytest`.
**Executor** **Executor**
@ -126,7 +126,7 @@ The `executor` property tells Nx what function to invoke when you run the target
**Options** **Options**
The `options` provides a map of values that will be passed to the executor. The provided command line args will be merged into this map. I.e., `nx test mylib --jestConfig=libs/mylib/another-jest.config.js` will pass the following to the executor: The `options` provides a map of values that are passed to the executor. The provided command line args are merged into this map. For example, `nx test mylib --jestConfig=libs/mylib/another-jest.config.js` passes the following to the executor:
```json ```json
{ {
@ -137,7 +137,7 @@ The `options` provides a map of values that will be passed to the executor. The
**Outputs** **Outputs**
The `outputs` property lists the folders the executor will create files in. The property is optional. If not provided, Nx will assume it is `dist/libs/mylib`. The `outputs` property lists the folders the executor creates files in. The property is optional. If not provided, Nx assumes it is `dist/libs/mylib`.
```json ```json
{ {
@ -154,7 +154,7 @@ The `outputs` property lists the folders the executor will create files in. The
**Configurations** **Configurations**
The `configurations` property provides extra sets of values that will be merged into the options map. The `configurations` property provides extra sets of values that are merged into the options map.
```json ```json
{ {
@ -207,11 +207,11 @@ Targets can depend on other targets. A common scenario is having to build depend
} }
``` ```
In this case, running `nx build myapp` will build all the buildable libraries `myapp` depends on first. In other words, `nx build myapp` will result in multiple tasks executing. The `--parallel`, and `--max-parallel` flags will have the same effect as they would with `run-many` or `affected`. In this case, running `nx build myapp` builds all the buildable libraries `myapp` depends on first. In other words, `nx build myapp` results in multiple tasks executing. The `--parallel`, and `--max-parallel` flags have the same effect as they would with `run-many` or `affected`.
It is also possible to define dependencies between the targets of the same project. It is also possible to define dependencies between the targets of the same project.
In the following example invoking `nx build myapp` will build all the libraries first, then `nx build-base myapp` will be executed and only then `nx build myapp` will be executed. In the following example invoking `nx build myapp` builds all the libraries first, then `nx build-base myapp` is executed and only then `nx build myapp` is executed.
```json ```json
{ {
@ -242,11 +242,11 @@ In the following example invoking `nx build myapp` will build all the libraries
} }
``` ```
Often the same `dependsOn` configuration has to be defined for every project in the repo. You can define it once in `nx.json` (see below). Often the same `dependsOn` configuration has to be defined for every project in the repo. Define it globally once in `nx.json` (see below).
### Generators ### Generators
You can configure default generator options in `workspace.json` as well. For instance, the following will tell Nx to always pass `--js` when creating new libraries. Default generator options are configured in `workspace.json` as well. For instance, the following tells Nx to always pass `--js` when creating new libraries.
```json ```json
{ {
@ -278,7 +278,7 @@ You can also do it on the project level:
### CLI Options ### CLI Options
The following command will generate a new library: `nx g @nrwl/react:lib mylib`. If you set the `defaultCollection` property, you can generate the lib without mentioning the collection name: `nx g lib mylib`. The following command generates a new library: `nx g @nrwl/react:lib mylib`. After setting the `defaultCollection` property, the lib is generated without mentioning the collection name: `nx g lib mylib`.
```json ```json
{ {
@ -379,22 +379,22 @@ Tells Nx which branch and HEAD to use when calculating affected projects.
### Tasks Runner Options ### Tasks Runner Options
Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, etc.. The tasks runner named "default" will be, unsurprisingly, used by default. But you can specify a different one by passing `--runner`. Tasks runners are invoked when you run `nx test`, `nx build`, `nx run-many`, `nx affected`, and so on. The tasks runner named "default" is used by default. Specify a different one by passing `--runner`.
> A task is an invocation of a target. > A task is an invocation of a target.
Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`. Tasks runners can accept different options. The following are the options supported by `"@nrwl/workspace/tasks-runners/default"` and `"@nrwl/nx-cloud"`.
- `cacheableOperations` defines the list of targets/operations that will be cached by Nx. - `cacheableOperations` defines the list of targets/operations that are cached by Nx.
- `parallel` defines whether to run targets in parallel - `parallel` defines whether to run targets in parallel
- `maxParallel` defines the max number of processes used. - `maxParallel` defines the max number of processes used.
- `captureStderr` defines whether the cache will capture stderr or just stdout - `captureStderr` defines whether the cache captures stderr or just stdout
- `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false` - `skipNxCache` defines whether the Nx Cache should be skipped. Defaults to `false`
- `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default. - `cacheDirectory` defines where the local cache is stored, which is `node_modules/.cache/nx` by default.
- `encryptionKey` (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner will normalize the key length, so any length of key is acceptable. - `encryptionKey` (when using `"@nrwl/nx-cloud"` only) defines an encryption key to support end-to-end encryption of your cloud cache. You may also provide an environment variable with the key `NX_CLOUD_ENCRYPTION_KEY` that contains an encryption key as its value. The Nx Cloud task runner normalizes the key length, so any length of key is acceptable.
- `runtimeCacheInputs` defines the list of commands that will be run by the runner to include into the computation hash value. - `runtimeCacheInputs` defines the list of commands that are run by the runner to include into the computation hash value.
`runtimeCacheInputs` can be set as follows: `runtimeCacheInputs` are set as follows:
```json ```json
{ {
@ -437,12 +437,12 @@ Nx performs advanced source-code analysis to figure out the project graph of the
In the example above: In the example above:
- Changing `workspace.json` will affect every project. - Changing `workspace.json` affects every project.
- Changing the `dependencies` property in `package.json` will affect every project. - Changing the `dependencies` property in `package.json` affects every project.
- Changing the `devDependencies` property in `package.json` will only affect `mylib`. - Changing the `devDependencies` property in `package.json` only affects `mylib`.
- Changing any of the custom check `scripts` in `package.json` will affect every project. - Changing any of the custom check `scripts` in `package.json` affects every project.
- Changing `globalFile` will only affect `myapp`. - Changing `globalFile` only affects `myapp`.
- Changing any CSS file inside the `styles` directory will only affect `myapp`. - Changing any CSS file inside the `styles` directory only affects `myapp`.
You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well. You can also add dependencies between projects. For instance, the example below defines a dependency from `myapp-e2e` to `myapp`, such that every time `myapp` is affected, `myapp-e2e` is affected as well.
@ -460,7 +460,7 @@ You can also add dependencies between projects. For instance, the example below
} }
``` ```
> Projects utilizing `project.json` files will not be present in `nx.json`. > Projects utilizing `project.json` files are not present in `nx.json`.
### Target Dependencies ### Target Dependencies
@ -493,5 +493,5 @@ The syntax is the same as a [`.gitignore` file](https://git-scm.com/book/en/v2/G
**When a file is specified in the `.nxignore` file:** **When a file is specified in the `.nxignore` file:**
1. Changes to that file will not be taken into account in the `affected` calculations. 1. Changes to that file are not taken into account in the `affected` calculations.
2. Even if the file is outside an app or library, `nx workspace-lint` will not warn about it. 2. Even if the file is outside an app or library, `nx workspace-lint` won't warn about it.