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

docs(nxdev): updates

Browse Source
This commit is contained in:
Isaac Mann 2022-01-07 23:01:40 -05:00 committed by Victor Savkin
parent 3845a55cf9
commit ef8986df47
3 changed files with 25 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/shared/configuration/packagejson.md
View File

@ -3,7 +3,7 @@
There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration) There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration)
and [the global Nx CLI configuration](#cli-configuration). and [the global Nx CLI configuration](#cli-configuration).
Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (when you Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (if you
use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two
files to get each project's configuration. This guide covers the `package.json` case. files to get each project's configuration. This guide covers the `package.json` case.
@ -62,7 +62,7 @@ You can add Nx-specific configuration as follows:
is actually the default, so we can omit it in this case. `"outputs": []` tells Nx that the `test` target doesn't create is actually the default, so we can omit it in this case. `"outputs": []` tells Nx that the `test` target doesn't create
any artifacts on disk. any artifacts on disk.
This configuration is actually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the
configuration above. configuration above.
### dependsOn ### dependsOn
@ -72,14 +72,14 @@ Targets can depend on other targets.
A common scenario is having to build dependencies of a project first before building the project. This is what A common scenario is having to build dependencies of a project first before building the project. This is what
the `dependsOn` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make the `dependsOn` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make
sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right
artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but there are available artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but they are available
in cache, Nx will retrieve them from the cache. in the cache, Nx will retrieve them from the cache.
Another common scenario is for a target to depend on another target of the same project. For instance, `dependsOn` of Another common scenario is for a target to depend on another target of the same project. For instance, `dependsOn` of
the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will
result in `mylib`'s dependencies being built as well. result in `mylib`'s dependencies being built as well.
This configuration is actually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the
configuration above. configuration above.
### tags ### tags
@ -95,8 +95,7 @@ You can annotate your projects with `tags` as follows:
} }
``` ```
Nx uses tags for linting to, for instance, ensure that private libraries aren't depended on by the team who don't own You can [configure lint rules using these tags](/structure/monorepo-tags) to, for instance, ensure that libraries belonging to `myteam` are not depended on by libraries belong to `theirteam`.
them.
### implicitDependencies ### implicitDependencies
@ -128,8 +127,7 @@ project, add the following to its `package.json`:
### workspace json ### workspace json
The `workspace.json` is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx The `workspace.json` file in the root directory is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx scanning the file tree for all `project.json` and `package.json` files.
scanning the file tree for all `project.json` and `package.json` files.
```json ```json
{ {
@ -283,7 +281,7 @@ every build target of every project.
### CLI Options ### CLI Options
The following command generates a new library: `nx g @nrwl/js:lib mylib`. After setting the `defaultCollection`property, The following command generates a new library: `nx g @nrwl/js:lib mylib`. After setting the `defaultCollection`property,
the lib is generated without mentioning the collection name: `nx g lib mylib`. the lib is generated without mentioning the plugin name: `nx g lib mylib`.
```json ```json
{ {

24
docs/shared/configuration/projectjson.md
View File

@ -3,7 +3,7 @@
There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration) There are two main types of configuration in every Nx workspace: [project configuration](#project-configuration)
and [the global Nx CLI configuration](#cli-configuration). and [the global Nx CLI configuration](#cli-configuration).
Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (when you Projects can be configured in `package.json` (if you use npm scripts and not Nx executors) and `project.json` (if you
use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two use Nx executors). Both `package.json` and `project.json` files are located in each project's folder. Nx merges the two
files to get each project's configuration. This guide covers the `project.json` case. files to get each project's configuration. This guide covers the `project.json` case.
@ -149,7 +149,7 @@ The `configurations` property provides extra sets of values that will be merged
You can select a configuration like this: `nx build mylib --configuration=production` You can select a configuration like this: `nx build mylib --configuration=production`
or `nx run mylib:build:configuration=production`. or `nx run mylib:build:configuration=production`.
The following show how the executor options get constructed: The following code snippet shows how the executor options get constructed:
```javascript ```javascript
require(`@nrwl/jest`).executors['jest']({ ...options, ...selectedConfiguration, ...commandLineArgs } require(`@nrwl/jest`).executors['jest']({ ...options, ...selectedConfiguration, ...commandLineArgs }
@ -172,20 +172,27 @@ Targets can depend on other targets.
A common scenario is having to build dependencies of a project first before building the project. This is what A common scenario is having to build dependencies of a project first before building the project. This is what
the `dependsOn` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make the `dependsOn` property of the `build` target configures. It tells Nx that before it can build `mylib` it needs to make
sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right sure that `mylib`'s dependencies are built as well. This doesn't mean Nx is going to rerun those builds. If the right
artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but there are available artifacts are already in the right place, Nx will do nothing. If they aren't in the right place, but they are available
in cache, Nx will retrieve them from the cache. in the cache, Nx will retrieve them from the cache.
Another common scenario is for a target to depend on another target of the same project. For instance, `dependsOn` of Another common scenario is for a target to depend on another target of the same project. For instance, `dependsOn` of
the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will the `test` target tells Nx that before it can test `mylib` it needs to make sure that `mylib` is built, which will
result in `mylib`'s dependencies being built as well. result in `mylib`'s dependencies being built as well.
This configuration is actually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the This configuration is usually not needed. Nx comes with reasonable defaults (imported in `nx.json`) which implement the
configuration above. configuration above.
### tags ### tags
Nx uses tags for linting to, for instance, ensure that private libraries aren't depended on by the team who don't own You can annotate your projects with `tags` as follows:
them.
```jsonc
{
"tags": ["scope:myteam"]
}
```
You can [configure lint rules using these tags](/structure/monorepo-tags) to, for instance, ensure that libraries belonging to `myteam` are not depended on by libraries belong to `theirteam`.
### implicitDependencies ### implicitDependencies
@ -204,8 +211,7 @@ statically, so you can set them manually like this:
### workspace json ### workspace json
The `workspace.json` is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx The `workspace.json` file in the root directory is optional. It's used if you want to list the projects in your workspace explicitly instead of Nx scanning the file tree for all `project.json` and `package.json` files.
scanning the file tree for all `project.json` and `package.json` files.
```json ```json
{ {

4
docs/shared/using-nx/nx-cli.md
View File

@ -63,7 +63,7 @@ Again, like `nx run`, `nx generate` is only an abstraction over generating code.
want via **generators**. **[Generators](/generators/using-schematics)** can be installed as part of a want via **generators**. **[Generators](/generators/using-schematics)** can be installed as part of a
plugin or developed locally within an Nx workspace to fit the needs of your organization. plugin or developed locally within an Nx workspace to fit the needs of your organization.
A [Workspace Generator](/generators/workspace-generators) is custom generator for your A [Workspace Generator](/generators/workspace-generators) is a custom generator for your
workspace. `nx generate workspace-generator my-generator` generates a workspace generator which can be run with workspace. `nx generate workspace-generator my-generator` generates a workspace generator which can be run with
the [`nx workspace-generator` command](/cli/workspace-generator). This can be useful to allow your the [`nx workspace-generator` command](/cli/workspace-generator). This can be useful to allow your
organization to consistently generate projects according to your own standards. organization to consistently generate projects according to your own standards.
@ -86,7 +86,7 @@ nx migrate --run-migrations # Runs the migrations scheduled by the previous comm
Nx creates and maintains a dependency graph between projects based on import statements in your code and uses that Nx creates and maintains a dependency graph between projects based on import statements in your code and uses that
information to run executors only on the [affected](/cli/affected) projects in a codebase. A visual information to run executors only on the [affected](/cli/affected) projects in a codebase. A visual
version of the [dependency graph](/structure/dependency-graph) is also available to help developers version of the [project dependency graph](/structure/dependency-graph) is also available to help developers
understand the architecture of the codebase. understand the architecture of the codebase.
The [`nx dep-graph` command](/cli/dep-graph) displays this dependency graph in a web browser for you to The [`nx dep-graph` command](/cli/dep-graph) displays this dependency graph in a web browser for you to