@@ -5,6 +5,27 @@ _[Please make sure you have read the submission guidelines before posting an PR]
Thanks for submitting your Nx Plugin to our community plugins list. Make sure to follow these steps to ensure that your PR is approved in a timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the registry. If the plugins become maintained again, they can be resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for your plugin that includes `name`, `url`, `description`:
@@ -21,7 +42,7 @@ Example:
}]
```
Once merged, your will plugin will be available when running the `nx list` command, and will also be available in the Plugin browser on [nx.dev](https://nx.dev)
Once merged, your plugin will be available when running the `nx list` command, and will also be available in the Plugin Registry on [nx.dev](https://nx.dev/extending-nx/registry)
uses:dawidd6/action-download-artifact@v2# Needed since we are downloading artifact from a different workflow run, official actions/download-artifact doesn't support this.
issue-inactive-days:"30"# Lock issues after 30 days of being closed
pr-inactive-days:"5"# Lock closed PRs after 5 days. This ensures that issues that stem from a PR are opened as issues, rather than comments on the recently merged PR.
add-issue-labels:"outdated"
issue-comment:>
This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.
pr-comment:>
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request.
@@ -35,20 +35,35 @@ Source code and documentation are included in the top-level folders listed below
-`scripts` - Miscellaneous scripts for project tasks such as building documentation, testing, and code formatting.
-`tmp` - Folder used by e2e tests. If you are a WebStorm user, make sure to mark this folder as excluded.
## Development Workstation Setup
If you are using `VSCode`, and provided you have [Docker](https://docker.com) installed on your machine, then you can leverage [Dev Containers](https://containers.dev) through this [VSCode extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers), to easily setup your development environment, with everything needed to contribute to Nx, already installed (namely `NodeJS`, `Yarn`, `Rust`, `Cargo`, plus some useful extensions like `Nx Console`).
To do so, simply:
- Checkout the repo
- Open it with VSCode
- Open the [Command Palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette) and select "Dev Containers: Open Folder in Container..."
The repo comes with a preconfigured `devcontainer.json` file (located in `.devcontainer/` folder at root), that `VSCode` will automatically use to install the aforementioned tools, inside a Docker image. It will even run `pnpm install` for you, so you can start contributing to Nx right after.
If you open the repo in [Github Codespace](https://github.com/features/codespaces), it will also leverage this config file, to setup the codespace, with the same required tools.
## Building the Project
> Nx uses Rust to build native bindings for Node. Please make sure that you have Rust installed via [rustup.rs](https://rustup.rs)
> If you have VSCode + Docker, this can be automated for you, see [section](#development-workstation-setup) above
After cloning the project to your machine, to install the dependencies, run:
```bash
yarn
pnpm i
```
To build all the packages, run:
```bash
yarn build
pnpm build
```
## Publishing to a local registry
@@ -58,19 +73,16 @@ it can be useful to publish to a local registry.
Check out [this video for a live walkthrough](https://youtu.be/Tx257WpNsxc) or follow the instructions below:
- Run `yarn local-registry start` in Terminal 1 (keep it running)
- Run `pnpm local-registry` in Terminal 1 (keep it running)
- Run `npm adduser --registry http://localhost:4873` in Terminal 2 (real credentials are not required, you just need to
be logged in. You can use test/test/test@test.io.)
- Run `yarn local-registry enable` in Terminal 2
- Run `yarn nx-release 16.0.0 --local` in Terminal 2 - you can choose any nonexistent version number here, but it's recommended to use the next major
- Run `pnpm nx-release 17.0.0 --local` in Terminal 2 - you can choose any nonexistent version number here, but it's recommended to use the next major
- Run `cd ./tmp` in Terminal 2
- Run `npx create-nx-workspace@16.0.0` in Terminal 2
- Run `npx create-nx-workspace@17.0.0` in Terminal 2
If you have problems publishing, make sure you use Node 18 and NPM 8.
**NOTE:**After you finish with local testing don't forget to stop the local registry (e.g. closing the Terminal 1) and disabling the local registy using `yarn local-registry disable`. Keeping local registry enabled will change your lock file resolutions to `localhost:4873` on the next `yarn install`. You can also run `yarn local-registry clear` to clean all packagesin that local registry.
**NOTE:** To use this newly published local version, you need to make a new workspace or change all of your target packages to this new version, eg: `"@nrwl/cli": "^16.0.0",` and re-run `yarn install` in your testing project.
**NOTE:**To use this newly published local version, you need to make a new workspace or change all of your target packages to this new version, eg: `"nx": "^17.0.0",` and re-run `pnpm i` in your testing project.
### Publishing for Yarn 2+ (Berry)
@@ -78,13 +90,15 @@ Yarn Berry operates slightly differently than Yarn Classic. In order to publish
- Run `yarn set version berry` to switch to latest Yarn version.
- Create `.yarnrc.yml` in root with following contents:
```yml
nodeLinker: node-modules
npmRegistryServer: 'http://localhost:4873'
unsafeHttpWhitelist:
- localhost
```
- Run `yarn local-registry start` in Terminal 1 (keep it running)
- Run `pnpm local-registry` in Terminal 1 (keep it running)
- If you are creating nx workspace outside of your nx repo, make sure to add npm registry info to your root yarnrc (
usually in ~/.yarnrc.yml). The file should look something like this:
@@ -93,13 +107,12 @@ Yarn Berry operates slightly differently than Yarn Classic. In order to publish
'https://registry.yarnpkg.com':
npmAuthToken: npm_******************
yarnPath: .yarn/releases/yarn-3.2.2.cjs
npmRegistryServer: 'http://localhost:4873'
unsafeHttpWhitelist:
- localhost
```
- Run `yarn nx-release --local` in Terminal 2 to publish next minor version. If this version already exists, you can
- Run `pnpm nx-release --local` in Terminal 2 to publish next minor version. If this version already exists, you can
bump the minor version in `lerna.json` to toggle the next minor. The output will report the version of published
packages.
- Go to your target folder (e.g. `cd ./tmp`) in Terminal 2
@@ -126,19 +139,19 @@ nx test jest
To make sure your changes do not break any E2E tests, run:
```bash
nx e2e e2e-cli # or any other project here
nx e2e e2e-vite # or any other project here
```
Running E2E tests can take some time, so it is often useful to run a single test. To run a single suite of tests, run:
```bash
nx e2e e2e-cli -t versions # I often add qqqq to my test name so I can use -t qqqq
nx e2e e2e-vite -t versions # I often add qqqq to my test name so I can use -t qqqq
```
Sometimes tests pass locally but they fail on the CI. To reproduce the CI environment and be able to debug the issue, run:
```bash
NX_VERBOSE_LOGGING=true CI=true SELECTED_PM=pnpm yarn nx e2e e2e-cli --t="should do something is this test"
NX_VERBOSE_LOGGING=true CI=true SELECTED_PM=pnpm pnpm nx e2e e2e-vite --t="should do something is this test"
```
The above command sets verbose logging (this exposes stack traces and underlying errors), sets the defaults to be CI-like and sets Pnpm as the selected package manager.
@@ -147,7 +160,7 @@ The above command sets verbose logging (this exposes stack traces and underlying
To build Nx on Windows, you need to use WSL.
- Run `yarn install` in WSL. Yarn will compile several dependencies. If you don't run `install` in WSL, they will be
- Run `pnpm install` in WSL. Yarn will compile several dependencies. If you don't run `install` in WSL, they will be
compiled for Windows.
- Run `nx affected --target=test` and other commands in WSL.
@@ -184,7 +197,7 @@ corresponding `schema.json` file for the given command.
After adjusting the `schema.json` file, `.md` files for these commands can be generated by running:
```bash
yarn documentation
pnpm documentation
```
This will update the corresponding contents of the `docs` directory. These are generated automatically on push (via
@@ -235,7 +248,7 @@ reproducible scenario gives us wealth of important information without going bac
additional information, such as:
- the output of `nx report`
- `yarn.lock` or `package-lock.json`
- `yarn.lock` or `package-lock.json` or `pnpm-lock.yaml`
- and most importantly - a use-case that fails
A minimal reproduction allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are
@@ -261,9 +274,9 @@ Please follow the following guidelines:
- Make sure e2e tests pass (this can take a while, so you can always let CI check those) (`nx affected --target=e2e`)
- Target a specific e2e test with `nx e2e e2e-cypress`
- Make sure you run `nx format`
- Update documentation with `yarn documentation`. For documentation, check for spelling and grammatical errors.
- Update your commit message to follow the guidelines below (use `yarn commit` to automate compliance)
- `yarn check-commit` will check to make sure your commit messages are formatted correctly
- Update documentation with `pnpm documentation`. For documentation, check for spelling and grammatical errors.
- Update your commit message to follow the guidelines below (use `pnpm commit` to automate compliance)
- `pnpm check-commit` will check to make sure your commit messages are formatted correctly
#### Commit Message Guidelines
@@ -300,7 +313,7 @@ The scope must be one of the following:
- graph - anything graph app specific
- expo - anything Expo specific
- express - anything Express specific
- js - anything related to @nrwl/js package or general js/ts support
- js - anything related to @nx/js package or general js/ts support
- linter - anything Linter specific
- nest - anything Nest specific
- nextjs - anything Next specific
@@ -339,4 +352,4 @@ Closes #157
To simplify and automate the process of committing with this format,
**Nx is a [Commitizen](https://github.com/commitizen/cz-cli) friendly repository**, just do `git add` and
[](https://gitter.im/nrwl-nx/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
{% card title="Infer projects from package.json and project.json" description="Nx will now also include folders with package.json/project.json in its graph of projects. You can ignore any unwanted projects by adding the directory to .nxignore." type="external" url="https://github.com/nrwl/nx/releases/tag/15.0.0" /%}
@@ -5,6 +5,8 @@ description: 'Graph dependencies affected by changes'
# affected:graph
**Deprecated:** Use `nx graph --affected`, or `nx affected --graph` instead depending on which best suits your use case. The `affected:graph` command will be removed in Nx 18.
Graph dependencies affected by changes
## Usage
@@ -55,12 +57,6 @@ Open the project graph of the workspace in the browser, highlight the projects a
The name of the application when a preset with pregenerated app is selected
The name of the app when using a monorepo with certain stacks
### bundler
Type: `string`
Bundler to be used to build the application
Bundler to be used to build the app
### ci
@@ -77,13 +77,21 @@ Default base to use for new projects
Type: `boolean`
Generate a Dockerfile with your node-server
Generate a Dockerfile for the Node API
### e2eTestRunner
Type: `string`
Choices: [cypress, playwright, none]
Test runner to use for end to end (E2E) tests.
### framework
Type: `string`
Framework option to be used when the node-server preset is selected
Framework option to be used with certain stacks
### help
@@ -95,6 +103,8 @@ Show help
Type: `boolean`
Default: `true`
Enable interactive mode with presets
### name
@@ -103,6 +113,12 @@ Type: `string`
Workspace name (e.g. org name)
### nextAppDir
Type: `boolean`
Enable the App Router for Next.js
### nxCloud
Type: `boolean`
@@ -123,13 +139,13 @@ Package manager to use
Type: `string`
Customizes the initial content of your workspace. Default presets include: ["apps", "empty", "core", "npm", "ts", "web-components", "angular-monorepo", "angular-standalone", "react-monorepo", "react-standalone", "react-native", "expo", "next", "nest", "express", "react", "angular", "node-server"]. To build your own see https://nx.dev/packages/nx-plugin#preset
Customizes the initial content of your workspace. Default presets include: ["apps", "empty", "core", "npm", "ts", "web-components", "angular-monorepo", "angular-standalone", "react-monorepo", "react-standalone", "next", "nextjs-standalone", "react-native", "expo", "nest", "express", "react", "angular", "node-standalone", "node-monorepo", "ts-standalone"]. To build your own see https://nx.dev/plugins/recipes/create-preset
### routing
Type: `string`
Type: `boolean`
Add a routing setup when a preset with pregenerated app is selected
Add a routing setup for an Angular app
### skipGit
@@ -137,11 +153,11 @@ Type: `boolean`
Default: `false`
Skip initializing a git repository.
Skip initializing a git repository
### standaloneApi
Type: `string`
Type: `boolean`
Use Standalone Components if generating an Angular app
@@ -149,10 +165,18 @@ Use Standalone Components if generating an Angular app
Type: `string`
Style option to be used when a preset with pregenerated app is selected
description: 'Adds nx.json file and installs nx if not installed already'
description: 'Adds Nx to any type of workspace. It installs nx, creates an nx.json configuration file and optionally sets up distributed caching. For more info, check https://nx.dev/recipes/adopting-nx.'
---
# init
Adds nx.json file and installs nx if not installed already
Adds Nx to any type of workspace. It installs nx, creates an nx.json configuration file and optionally sets up distributed caching. For more info, check https://nx.dev/recipes/adopting-nx.
## Usage
@@ -14,3 +14,71 @@ nx init
```
Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`, `yarn nx`, or `pnpm nx`.
## Options
### addE2e
Type: `boolean`
Default: `false`
Set up Cypress E2E tests in integrated workspaces. Only for CRA projects.
### force
Type: `boolean`
Default: `false`
Force the migration to continue and ignore custom webpack setup or uncommitted changes. Only for CRA projects.
### help
Type: `boolean`
Show help
### integrated
Type: `boolean`
Default: `false`
Migrate to an Nx integrated layout workspace. Only for Angular CLI workspaces and CRA projects.
### interactive
Type: `boolean`
Default: `true`
When false disables interactive input prompts for options.
### nxCloud
Type: `boolean`
Set up distributed caching with Nx Cloud.
### useDotNxInstallation
Type: `boolean`
Default: `false`
Initialize an Nx workspace setup in the .nx directory of the current repository.
@@ -23,10 +23,10 @@ List the plugins installed in the current workspace:
nx list
```
List the generators and executors available in the `@nrwl/web` plugin if it is installed (If the plugin is not installed `nx` will show advice on how to add it to your workspace):
List the generators and executors available in the `@nx/web` plugin if it is installed (If the plugin is not installed `nx` will show advice on how to add it to your workspace):
'Creates a migrations file or runs migrations from the migrations file.
- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest)
- Run migrations (e.g., nx migrate --run-migrations=migrations.json)'
- Migrate packages and create migrations.json (e.g., nx migrate @nx/workspace@latest)
- Run migrations (e.g., nx migrate --run-migrations=migrations.json). Use flag --if-exists to run migrations only if the migrations file exists.'
---
# migrate
Creates a migrations file or runs migrations from the migrations file.
- Migrate packages and create migrations.json (e.g., nx migrate @nrwl/workspace@latest)
- Run migrations (e.g., nx migrate --run-migrations=migrations.json)
- Migrate packages and create migrations.json (e.g., nx migrate @nx/workspace@latest)
- Run migrations (e.g., nx migrate --run-migrations=migrations.json). Use flag --if-exists to run migrations only if the migrations file exists.
## Usage
@@ -23,28 +23,28 @@ Install `nx` globally to invoke the command directly using `nx`, or use `npx nx`
### Examples
Update @nrwl/workspace to "next". This will update other packages and will generate migrations.json:
Update all Nx plugins to "latest". This will generate migrations.json:
```shell
nx migrate next
nx migrate latest
```
Update @nrwl/workspace to "9.0.0". This will update other packages and will generate migrations.json:
Update all Nx plugins to "9.0.0". This will generate migrations.json:
```shell
nx migrate 9.0.0
```
Update @nrwl/workspace and generate the list of migrations starting with version 8.0.0 of @nrwl/workspace and @nrwl/node, regardless of what installed locally:
Update @nx/workspace and generate the list of migrations starting with version 8.0.0 of @nx/workspace and @nx/node, regardless of what is installed locally:
Update another-package to "12.0.0". This will update other packages and will generate migrations.json file:
@@ -53,6 +53,18 @@ Update another-package to "12.0.0". This will update other packages and will gen
nx migrate another-package@12.0.0
```
Collect package updates and migrations in interactive mode. In this mode, the user will be prompted whether to apply any optional package update and migration:
```shell
nx migrate latest --interactive
```
Collect package updates and migrations starting with version 14.5.0 of "nx" (and Nx first-party plugins), regardless of what is installed locally, while excluding migrations that should have been applied on previous updates:
@@ -5,6 +5,8 @@ description: 'Prints information about the projects and targets affected by chan
# print-affected
**Deprecated:** Use `nx show projects --affected`, `nx affected --graph -t build` or `nx graph --affected` depending on which best suits your use case. The `print-affected` command will be removed in Nx 18.
Prints information about the projects and targets affected by changes
## Usage
@@ -32,29 +34,23 @@ Print information about the projects affected by the changes between main and HE
Prints information about the affected projects and a list of tasks to test them:
```shell
nx print-affected --target=test
nx print-affected -t test
```
Prints the projects property from the print-affected output:
description: 'Runs an Architect target with an optional custom builder configuration defined in your project.'
description: 'Runs a target defined for your project. Target definitions can be found in the `scripts` property of the project `package.json`, or in the `targets` property of the project `project.json` file.'
---
# run
Runs an Architect target with an optional custom builder configuration defined in your project.
Runs a target defined for your project. Target definitions can be found in the `scripts` property of the project `package.json`, or in the `targets` property of the project `project.json` file.
**Deprecated:** workspace-lint is deprecated, and will be removed in v17. The checks it used to perform are no longer relevant. See: https://nx.dev/deprecated/workspace-lint
Lint nx specific workspace files (nx.json, workspace.json)
The latest version of Nx supports the [actively supported versions of Angular (current and LTS versions)](https://angular.io/guide/releases#actively-supported-versions). Workspaces in any of those versions are recommended to use the latest version of Nx to benefit from all the new features and fixes.
{% callout type="note" title="Older Nx and Angular versions" %}
The support for multiple versions of Angular in the latest version of Nx was added in **v15.7.0** and started by supporting Angular v14 and v15. If your workspace is in an older version of Angular or you can't update to the latest version of Nx for some reason, please have a look at the next section to know which version of Nx to use.
{% /callout %}
## Nx and Angular Version Compatibility Matrix
Below is a reference table that matches versions of Angular to the version of Nx that is compatible with it. The table shows the version of Angular, the recommended version of Nx to use and the range of Nx versions that support the version of Angular.
We provide a recommended version, and it is usually the latest minor version of Nx in the range provided because there will have been bug fixes added since the first release in the range.
| Angular Version | **Nx Version _(recommended)_** | Nx Version _(range)_ |
If you would like to see how the supported versions of Node and Typescript for the version of Angular you are using, [Lars Gyrup Brink Nielsen](https://twitter.com/LayZeeDK) has a very good resource for that [here](https://gist.github.com/LayZeeDK/c822cc812f75bb07b7c55d07ba2719b3).
Additionally, you can check the supported versions of Node and Typescript for the version of Angular you are using in the [Angular docs](https://angular.io/guide/versions#actively-supported-versions).
The Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides:
The Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries
within an Nx workspace. It provides:
- Integration with libraries such as Storybook, Jest, Cypress, Karma, and Protractor.
- Integration with libraries such as Storybook, Jest and Cypress.
- Generators to help scaffold code quickly, including:
- Micro Frontends
- Libraries, both internal to your codebase and publishable to npm
@@ -10,7 +11,8 @@ The Nx Plugin for Angular contains executors, generators, and utilities for mana
- Utilities for automatic workspace refactoring.
{% callout type="note" title="Currently using the Angular CLI?" %}
You can easily and mostly **automatically migrate from an Angular CLI** project to Nx! Learn more [here](/recipes/adopting-nx/migration-angular).
You can easily and mostly **automatically migrate from an Angular CLI** project to Nx! Learn
more [here](/recipes/angular/migration/angular).
{% /callout %}
## Setting up the Angular plugin
@@ -18,11 +20,11 @@ You can easily and mostly **automatically migrate from an Angular CLI** project
Adding the Angular plugin to an existing Nx workspace can be done with the following:
```shell
yarn add -D @nrwl/angular
yarn add -D @nx/angular
```
```shell
npm install -D @nrwl/angular
npm install -D @nx/angular
```
## Using the Angular Plugin
@@ -32,7 +34,7 @@ npm install -D @nrwl/angular
It's straightforward to generate an Angular application:
```shell
nx g @nrwl/angular:app appName
nx g @nx/angular:app appName
```
By default, the application will be generated with:
@@ -56,7 +58,7 @@ nx e2e appName
Generating an Angular library is very similar to generating an application:
"description":"List of static application assets.",
"default":[],
"items":{
"oneOf":[
{
"type":"object",
"properties":{
"followSymlinks":{
"type":"boolean",
"default":false,
"description":"Allow glob patterns to follow symlink directories. This allows subdirectories of the symlink to be searched."
},
"glob":{
"type":"string",
"description":"The pattern to match."
},
"input":{
"type":"string",
"description":"The input directory path in which to apply 'glob'. Defaults to the project root."
},
"ignore":{
"description":"An array of globs to ignore.",
"type":"array",
"items":{"type":"string"}
},
"output":{
"type":"string",
"description":"Absolute path within the output."
}
},
"additionalProperties":false,
"required":["glob","input","output"]
},
{"type":"string"}
]
}
},
"main":{
"type":"string",
"description":"The full path for the main entry point to the app, relative to the current workspace."
},
"polyfills":{
"description":"Polyfills to be included in the build.",
"oneOf":[
{
"type":"array",
"description":"A list of polyfills to include in the build. Can be a full path for a file, relative to the current workspace or module specifier. Example: 'zone.js'.",
"items":{"type":"string","uniqueItems":true},
"default":[]
},
{
"type":"string",
"description":"The full path for the polyfills file, relative to the current workspace or a module specifier. Example: 'zone.js'."
}
]
},
"tsConfig":{
"type":"string",
"description":"The full path for the TypeScript configuration file, relative to the current workspace."
},
"scripts":{
"description":"Global scripts to be included in the build.",
"type":"array",
"default":[],
"items":{
"oneOf":[
{
"type":"object",
"properties":{
"input":{
"type":"string",
"description":"The file to include.",
"pattern":"\\.[cm]?jsx?$"
},
"bundleName":{
"type":"string",
"pattern":"^[\\w\\-.]*$",
"description":"The bundle name for this extra entry point."
},
"inject":{
"type":"boolean",
"description":"If the bundle will be referenced in the HTML file.",
"default":true
}
},
"additionalProperties":false,
"required":["input"]
},
{
"type":"string",
"description":"The JavaScript/TypeScript file or package containing the file to include."
}
]
}
},
"styles":{
"description":"Global styles to be included in the build.",
"type":"array",
"default":[],
"items":{
"oneOf":[
{
"type":"object",
"properties":{
"input":{
"type":"string",
"description":"The file to include.",
"pattern":"\\.(?:css|scss|sass|less)$"
},
"bundleName":{
"type":"string",
"pattern":"^[\\w\\-.]*$",
"description":"The bundle name for this extra entry point."
},
"inject":{
"type":"boolean",
"description":"If the bundle will be referenced in the HTML file.",
"default":true
}
},
"additionalProperties":false,
"required":["input"]
},
{
"type":"string",
"description":"The file to include.",
"pattern":"\\.(?:css|scss|sass|less)$"
}
]
}
},
"inlineStyleLanguage":{
"description":"The stylesheet language to use for the application's inline component styles.",
"type":"string",
"default":"css",
"enum":["css","less","sass","scss"]
},
"stylePreprocessorOptions":{
"description":"Options to pass to style preprocessors.",
"type":"object",
"properties":{
"includePaths":{
"description":"Paths to include. Paths will be resolved to workspace root.",
"type":"array",
"items":{"type":"string"},
"default":[]
}
},
"additionalProperties":false
},
"externalDependencies":{
"description":"Exclude the listed external dependencies from being bundled into the bundle. Instead, the created bundle relies on these dependencies to be available during runtime.",
"type":"array",
"items":{"type":"string"},
"default":[]
},
"optimization":{
"description":"Enables optimization of the build output. Including minification of scripts and styles, tree-shaking, dead-code elimination, inlining of critical CSS and fonts inlining. For more information, see https://angular.io/guide/workspace-config#optimization-configuration.",
"default":true,
"x-user-analytics":"ep.ng_optimization",
"oneOf":[
{
"type":"object",
"properties":{
"scripts":{
"type":"boolean",
"description":"Enables optimization of the scripts output.",
"default":true
},
"styles":{
"description":"Enables optimization of the styles output.",
"default":true,
"oneOf":[
{
"type":"object",
"properties":{
"minify":{
"type":"boolean",
"description":"Minify CSS definitions by removing extraneous whitespace and comments, merging identifiers and minimizing values.",
"default":true
},
"inlineCritical":{
"type":"boolean",
"description":"Extract and inline critical CSS definitions to improve first paint time.",
"default":true
}
},
"additionalProperties":false
},
{"type":"boolean"}
]
},
"fonts":{
"description":"Enables optimization for fonts. This option requires internet access. `HTTPS_PROXY` environment variable can be used to specify a proxy server.",
"default":true,
"oneOf":[
{
"type":"object",
"properties":{
"inline":{
"type":"boolean",
"description":"Reduce render blocking requests by inlining external Google Fonts and Adobe Fonts CSS definitions in the application's HTML index file. This option requires internet access. `HTTPS_PROXY` environment variable can be used to specify a proxy server.",
"default":true
}
},
"additionalProperties":false
},
{"type":"boolean"}
]
}
},
"additionalProperties":false
},
{"type":"boolean"}
]
},
"fileReplacements":{
"description":"Replace compilation source files with other compilation source files in the build.",
"description":"The full path for the new output directory, relative to the current workspace.\nBy default, writes output to a folder named dist/ in the current project."
},
"resourcesOutputPath":{
"type":"string",
"description":"The path where style resources will be placed, relative to outputPath."
},
"aot":{
"type":"boolean",
"description":"Build using Ahead of Time compilation.",
"x-user-analytics":"ep.ng_aot",
"default":true
},
"sourceMap":{
"description":"Output source maps for scripts and styles. For more information, see https://angular.io/guide/workspace-config#source-map-configuration.",
"default":false,
"oneOf":[
{
"type":"object",
"properties":{
"scripts":{
"type":"boolean",
"description":"Output source maps for all scripts.",
"default":true
},
"styles":{
"type":"boolean",
"description":"Output source maps for all styles.",
"default":true
},
"hidden":{
"type":"boolean",
"description":"Output source maps used for error reporting tools.",
"description":"Generate a seperate bundle containing only vendor libraries. This option should only be used for development to reduce the incremental compilation time.",
"default":false
},
"commonChunk":{
"type":"boolean",
"description":"Generate a seperate bundle containing code used across multiple bundles.",
"default":true
},
"baseHref":{
"type":"string",
"description":"Base url for the application being built."
},
"deployUrl":{
"type":"string",
"description":"URL where files will be deployed.",
"x-deprecated":"Use \"baseHref\" option, \"APP_BASE_HREF\" DI token or a combination of both instead. For more information, see https://angular.io/guide/deployment#the-deploy-url."
},
"verbose":{
"type":"boolean",
"description":"Adds more details to output logging.",
"default":false
},
"progress":{
"type":"boolean",
"description":"Log progress to the console while building.",
"default":true
},
"i18nMissingTranslation":{
"type":"string",
"description":"How to handle missing translations for i18n.",
"enum":["warning","error","ignore"],
"default":"warning"
},
"i18nDuplicateTranslation":{
"type":"string",
"description":"How to handle duplicate translations for i18n.",
"enum":["warning","error","ignore"],
"default":"warning"
},
"localize":{
"description":"Translate the bundles in one or more locales.",
"oneOf":[
{"type":"boolean","description":"Translate all locales."},
{
"type":"array",
"description":"List of locales ID's to translate.",
"description":"Define the output filename cache-busting hashing mode.",
"default":"none",
"enum":["none","all","media","bundles"]
},
"poll":{
"type":"number",
"description":"Enable and define the file watching poll time period in milliseconds."
},
"deleteOutputPath":{
"type":"boolean",
"description":"Delete the output path before building.",
"default":true
},
"preserveSymlinks":{
"type":"boolean",
"description":"Do not use the real path when resolving modules. If unset then will default to `true` if NodeJS option --preserve-symlinks is set."
},
"extractLicenses":{
"type":"boolean",
"description":"Extract all licenses in a separate file.",
"default":true
},
"buildOptimizer":{
"type":"boolean",
"description":"Enables advanced build optimizations when using the 'aot' option.",
"default":true
},
"namedChunks":{
"type":"boolean",
"description":"Use file name for lazy loaded chunks.",
"default":false
},
"subresourceIntegrity":{
"type":"boolean",
"description":"Enables the use of subresource integrity validation.",
"default":false
},
"serviceWorker":{
"type":"boolean",
"description":"Generates a service worker config for production builds.",
"default":false
},
"ngswConfigPath":{
"type":"string",
"description":"Path to ngsw-config.json."
},
"index":{
"description":"Configures the generation of the application's HTML index.",
"oneOf":[
{
"type":"string",
"description":"The path of a file to use for the application's HTML index. The filename of the specified path will be used for the generated file and will be created in the root of the application's configured output path."
},
{
"type":"object",
"description":"",
"properties":{
"input":{
"type":"string",
"minLength":1,
"description":"The path of a file to use for the application's generated HTML index."
},
"output":{
"type":"string",
"minLength":1,
"default":"index.html",
"description":"The output path of the application's generated HTML index file. The full provided path will be used and will be considered relative to the application's configured output path."
}
},
"required":["input"]
},
{
"const":false,
"description":"Does not generate an `index.html` file."
}
]
},
"statsJson":{
"type":"boolean",
"description":"Generates a 'stats.json' file which can be analyzed using tools such as 'webpack-bundle-analyzer'.",
"default":false
},
"budgets":{
"description":"Budget thresholds to ensure parts of your application stay within boundaries which you set.",
"type":"array",
"items":{
"type":"object",
"properties":{
"type":{
"type":"string",
"description":"The type of budget.",
"enum":[
"all",
"allScript",
"any",
"anyScript",
"anyComponentStyle",
"bundle",
"initial"
]
},
"name":{
"type":"string",
"description":"The name of the bundle."
},
"baseline":{
"type":"string",
"description":"The baseline size for comparison."
},
"maximumWarning":{
"type":"string",
"description":"The maximum threshold for warning relative to the baseline."
},
"maximumError":{
"type":"string",
"description":"The maximum threshold for error relative to the baseline."
},
"minimumWarning":{
"type":"string",
"description":"The minimum threshold for warning relative to the baseline."
},
"minimumError":{
"type":"string",
"description":"The minimum threshold for error relative to the baseline."
},
"warning":{
"type":"string",
"description":"The threshold for warning relative to the baseline (min & max)."
},
"error":{
"type":"string",
"description":"The threshold for error relative to the baseline (min & max)."
}
},
"additionalProperties":false,
"required":["type"]
},
"default":[]
},
"webWorkerTsConfig":{
"type":"string",
"description":"TypeScript configuration for Web Worker modules."
},
"crossOrigin":{
"type":"string",
"description":"Define the crossorigin attribute setting of elements that provide CORS support.",
"default":"none",
"enum":["none","anonymous","use-credentials"]
},
"allowedCommonJsDependencies":{
"description":"A list of CommonJS packages that are allowed to be used without a build time warning.",
"type":"array",
"items":{"type":"string"},
"default":[]
},
"buildLibsFromSource":{
"type":"boolean",
"description":"Read buildable libraries from source instead of building them separately.",
"description":"List of remote applications to not automatically serve, either statically or in development mode. This can be useful for multi-repository module federation setups where the host application uses a remote application from an external repository."
"description":"List of remote applications to not automatically serve, either statically or in development mode."
},
"pathToManifestFile":{
"type":"string",
@@ -116,7 +116,7 @@
},
"additionalProperties":false,
"required":["browserTarget"],
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\nThe Module Federation Dev Server will serve a host application and find the remote applications associated with the host and serve them statically also. \nSee an example set up of it below:\n\n```json\n{\n \"serve\": {\n \"executor\": \"@nrwl/angular:module-federation-dev-server\",\n \"configurations\": {\n \"production\": {\n \"browserTarget\": \"host:build:production\"\n },\n \"development\": {\n \"browserTarget\": \"host:build:development\"\n }\n },\n \"defaultConfiguration\": \"development\",\n \"options\": {\n \"port\": 4200,\n \"publicHost\": \"http://localhost:4200\"\n }\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Serve host with remotes that can be live reloaded\" %}\nThe Module Federation Dev Server will serve a host application and find the remote applications associated with the host and serve a set selection with live reloading enabled also. \nSee an example set up of it below:\n\n```json\n{\n \"serve-with-hmr-remotes\": {\n \"executor\": \"@nrwl/angular:module-federation-dev-server\",\n \"configurations\": {\n \"production\": {\n \"browserTarget\": \"host:build:production\"\n },\n \"development\": {\n \"browserTarget\": \"host:build:development\"\n }\n },\n \"defaultConfiguration\": \"development\",\n \"options\": {\n \"port\": 4200,\n \"publicHost\": \"http://localhost:4200\",\n \"devRemotes\": [\"remote1\", \"remote2\"]\n }\n }\n}\n```\n\n{% /tab %}\n\n{% /tabs %}\n"
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\nThe Module Federation Dev Server will serve a host application and find the remote applications associated with the host and serve them statically also. \nSee an example set up of it below:\n\n```json\n{\n \"serve\": {\n \"executor\": \"@nx/angular:module-federation-dev-server\",\n \"configurations\": {\n \"production\": {\n \"browserTarget\": \"host:build:production\"\n },\n \"development\": {\n \"browserTarget\": \"host:build:development\"\n }\n },\n \"defaultConfiguration\": \"development\",\n \"options\": {\n \"port\": 4200,\n \"publicHost\": \"http://localhost:4200\"\n }\n }\n}\n```\n\n{% /tab %}\n\n{% tab label=\"Serve host with remotes that can be live reloaded\" %}\nThe Module Federation Dev Server will serve a host application and find the remote applications associated with the host and serve a set selection with live reloading enabled also. \nSee an example set up of it below:\n\n```json\n{\n \"serve-with-hmr-remotes\": {\n \"executor\": \"@nx/angular:module-federation-dev-server\",\n \"configurations\": {\n \"production\": {\n \"browserTarget\": \"host:build:production\"\n },\n \"development\": {\n \"browserTarget\": \"host:build:development\"\n }\n },\n \"defaultConfiguration\": \"development\",\n \"options\": {\n \"port\": 4200,\n \"publicHost\": \"http://localhost:4200\",\n \"devRemotes\": [\"remote1\", \"remote2\"]\n }\n }\n}\n```\n\n{% /tab %}\n\n{% /tabs %}\n"
},
"description":"The module-federation-dev-server executor is reserved exclusively for use with host Module Federation applications. It allows the user to specify which remote applications should be served with the host.",
"description":"List of remote applications to not automatically serve, either statically or in development mode. This can be useful for multi-repository module federation setups where the host application uses a remote application from an external repository."
"description":"List of remote applications to not automatically serve, either statically or in development mode."
},
"verbose":{
"type":"boolean",
"description":"Adds more details to output logging."
"description":"Adds more details to output logging.",
"description":"Builds a library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nrwl/angular:package` executor but with some key differences:\n- It doesn't run `ngcc` automatically (`ngcc` needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2020 bundles.\n- It doesn't generate package exports in the `package.json`.",
"description":"Builds a library with support for incremental builds.\n\nThis executor is meant to be used with buildable libraries in an incremental build scenario. It is similar to the `@nx/angular:package` executor but with some key differences:\n- For supported Angular versions lower than v16, it doesn't run `ngcc` automatically (`ngcc` is no longer available from Angular v16 onwards, for lower versions, it needs to be run separately beforehand if needed, this can be done in a `postinstall` hook on `package.json`).\n- It only produces ESM2022 bundles (ESM2020 for supported Angular versions lower than v16).",
"cli":"nx",
"type":"object",
"presets":[
@@ -16,11 +16,7 @@
},
{
"name":"Updating Project Dependencies for Buildable Library",
"keys":[
"project",
"updateBuildableProjectDepsInPackageJson",
"buildableProjectDepsInPackageJsonType"
]
"keys":["project"]
}
],
"properties":{
@@ -42,14 +38,16 @@
},
"updateBuildableProjectDepsInPackageJson":{
"type":"boolean",
"description":"Whether to update the buildable project dependencies in package.json.",
"default":true
"description":"Whether to update the buildable project dependencies in the build output package.json.",
"default":false,
"x-deprecated":"Configure the project to use the '@nx/dependency-checks' ESLint rule instead (https://nx.dev/packages/eslint-plugin/documents/dependency-checks). It will be removed in v17."
},
"buildableProjectDepsInPackageJsonType":{
"type":"string",
"description":"When `updateBuildableProjectDepsInPackageJson` is `true`, this adds dependencies to either `peerDependencies` or `dependencies`.",
"enum":["dependencies","peerDependencies"],
"default":"peerDependencies"
"default":"peerDependencies",
"x-deprecated":"Configure the '@nx/dependency-checks' ESLint rule instead (https://nx.dev/packages/eslint-plugin/documents/dependency-checks). It will be removed in v17."
"name":"Updating Project Dependencies for Publishable Library",
"keys":[
"project",
"updateBuildableProjectDepsInPackageJson",
"buildableProjectDepsInPackageJsonType"
"project"
]
}
],
@@ -45,8 +43,9 @@
},
"updateBuildableProjectDepsInPackageJson":{
"type":"boolean",
"description":"Whether to update the buildable project dependencies in package.json.",
"default":true
"description":"Whether to update the buildable project dependencies in the build output package.json.",
"default":false,
"x-deprecated":"Configure the project to use the '@nx/dependency-checks' ESLint rule instead (https://nx.dev/packages/eslint-plugin/documents/dependency-checks). It will be removed in v17."
},
"buildableProjectDepsInPackageJsonType":{
"type":"string",
@@ -55,7 +54,8 @@
"dependencies",
"peerDependencies"
],
"default":"peerDependencies"
"default":"peerDependencies",
"x-deprecated":"Configure the project to use the '@nx/dependency-checks' ESLint rule instead (https://nx.dev/packages/eslint-plugin/documents/dependency-checks). It will be removed in v17."
"description":"The webpack-browser executor is very similar to the standard browser builder provided by the Angular Devkit. It allows you to build your Angular application to a build artifact that can be hosted online. There are some key differences: \n- Supports Custom Webpack Configurations \n- Supports Incremental Building",
"examplesFile":"##### Using a custom webpack configuration\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n \"executor\": \"@nrwl/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications. \n> You can read more about when to use incremental builds [here](/more-concepts/incremental-builds#when-should-i-use-incremental-builds).\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n \"executor\": \"@nrwl/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n}\n```\n",
"examplesFile":"##### Using a custom webpack configuration\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications. \n> You can read more about when to use incremental builds [here](/concepts/more-concepts/incremental-builds#when-should-i-use-incremental-builds).\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"buildLibsFromSource\": false\n }\n}\n```\n",
"type":"object",
"presets":[
{
@@ -330,7 +330,7 @@
},
"vendorChunk":{
"type":"boolean",
"description":"Generate a seperate bundle containing only vendor libraries. This option should only used for development.",
"description":"Generate a seperate bundle containing only vendor libraries. This option should only be used for development to reduce the incremental compilation time.",
"description":"The webpack-dev-server executor is very similar to the standard dev server builder provided by the Angular Devkit. It is usually used in tandem with `@nrwl/angular:webpack-browser` when your Angular application uses a custom webpack configuration.",
"examplesFile":"##### Seving an application with a custom webpack configuration\n\nThis executor should be used along with `@nrwl/angular:webpack-browser` to serve an application using a custom webpack configuration.\n\nYour `project.json` file should contain a `build` and `serve` target that matches the following:\n\n```json\n\"build\": {\n \"executor\": \"@nrwl/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n},\n\"serve\": {\n \"executor\": \"@nrwl/angular:webpack-dev-server\",\n \"configurations\": {\n \"production\": {\n \"browserTarget\": \"appName:build:production\"\n },\n \"development\": {\n \"browserTarget\": \"appName:build:development\"\n }\n },\n \"defaultConfiguration\": \"development\",\n}\n```\n",
"description":"The webpack-dev-server executor is very similar to the standard dev server builder provided by the Angular Devkit. It is usually used in tandem with `@nx/angular:webpack-browser` when your Angular application uses a custom webpack configuration.",
"examplesFile":"##### Seving an application with a custom webpack configuration\n\nThis executor should be used along with `@nx/angular:webpack-browser` to serve an application using a custom webpack configuration.\n\nYour `project.json` file should contain a `build` and `serve` target that matches the following:\n\n```json\n\"build\": {\n \"executor\": \"@nx/angular:webpack-browser\",\n \"options\": {\n ...\n \"customWebpackConfig\": {\n \"path\": \"apps/appName/webpack.config.js\"\n }\n }\n},\n\"serve\": {\n \"executor\": \"@nx/angular:webpack-dev-server\",\n \"configurations\": {\n \"production\": {\n \"browserTarget\": \"appName:build:production\"\n },\n \"development\": {\n \"browserTarget\": \"appName:build:development\"\n }\n },\n \"defaultConfiguration\": \"development\",\n}\n```\n",
"type":"object",
"presets":[
{"name":"Using a Different Port","keys":["browserTarget","port"]}
"description":"The webpack-dev-server executor is very similar to the standard server builder provided by the Angular Devkit. It is usually used in tandem with `@nrwl/angular:webpack-browser` when your Angular application uses a custom webpack configuration and NgUniversal for SSR.",
"description":"The webpack-dev-server executor is very similar to the standard server builder provided by the Angular Devkit. It is usually used in tandem with `@nx/angular:webpack-browser` when your Angular application uses a custom webpack configuration and NgUniversal for SSR.",
"type":"object",
"properties":{
"assets":{
@@ -185,6 +185,11 @@
"description":"URL where files will be deployed.",
"x-deprecated":"Use \"baseHref\" browser builder option, \"APP_BASE_HREF\" DI token or a combination of both instead. For more information, see https://angular.io/guide/deployment#the-deploy-url."
},
"vendorChunk":{
"type":"boolean",
"description":"Generate a seperate bundle containing only vendor libraries. This option should only be used for development to reduce the incremental compilation time. _Note: supported in Angular versions >= 15.1.0_",
"default":false
},
"verbose":{
"type":"boolean",
"description":"Adds more details to output logging.",
@@ -242,6 +247,11 @@
"description":"Extract all licenses in a separate file, in the case of production builds only.",
"default":true
},
"buildOptimizer":{
"type":"boolean",
"description":"Enables advanced build optimizations. _Note: only supported in Angular versions >= 16.0.0_.",
"default":true
},
"namedChunks":{
"type":"boolean",
"description":"Use file name for lazy loaded chunks.",
"command":"nx g @nrwl/angular:add-linting --prefix=cool --projectName=cool-lib --projectRoot=libs/cool-lib",
"command":"nx g @nx/angular:add-linting --prefix=cool --projectName=cool-lib --projectRoot=libs/cool-lib",
"description":"Adds ESLint with Angular-specific rules for an existing project named `cool-lib` with the [prefix](https://angular.io/guide/styleguide#style-02-07) `cool`"
"description":"Test runner to use for unit tests.",
"default":"jest"
},
"e2eTestRunner":{
"type":"string",
"enum":["protractor","cypress","none"],
"description":"Test runner to use for end to end (E2E) tests. The `protractor` option is deprecated and it will be removed in v15.",
"enum":["cypress","playwright","none"],
"description":"Test runner to use for end to end (E2E) tests.",
"x-prompt":"Which E2E test runner would you like to use?",
"default":"cypress"
},
"tags":{
@@ -161,11 +162,17 @@
"description":"Generate a Angular app with a minimal setup.",
"type":"boolean",
"default":false
},
"bundler":{
"description":"Bundler to use to build the application.",
"type":"string",
"enum":["webpack","esbuild"],
"default":"webpack"
}
},
"additionalProperties":false,
"required":["name"],
"examplesFile":"## Examples\n\n{% tabs %}\n{% tab label=\"Simple Application\" %}\n\nCreate an application named `my-app`:\n\n```bash\nnx g @nrwl/angular:application my-app\n```\n\n{% /tab %}\n\n{% tab label=\"Specify directory and style extension\" %}\n\nCreate an application named `my-app` in the `my-dir` directory and use `scss` for styles:\n\n```bash\nnx g @nrwl/angular:app my-app --directory=my-dir --style=scss\n```\n\n{% /tab %}\n\n{% tab label=\"Single File Components application\" %}\n\nCreate an application with Single File Components (inline styles and inline templates):\n\n```bash\nnx g @nrwl/angular:app my-app --inlineStyle --inlineTemplate\n```\n\n{% /tab %}\n\n{% tab label=\"Standalone Components application\" %}\n\nCreate an application that is setup to use standalone components:\n\n```bash\nnx g @nrwl/angular:app my-app --standalone\n```\n\n{% /tab %}\n\n{% tab label=\"Set custom prefix and tags\" %}\n\nSet the prefix to apply to generated selectors and add tags to the application (used for linting).\n\n```bash\nnx g @nrwl/angular:app my-app --prefix=admin --tags=scope:admin,type:ui\n```\n\n{% /tab %}\n{% /tabs %}\n",
"examplesFile":"## Examples\n\n{% tabs %}\n{% tab label=\"Simple Application\" %}\n\nCreate an application named `my-app`:\n\n```bash\nnx g @nx/angular:application my-app\n```\n\n{% /tab %}\n\n{% tab label=\"Specify directory and style extension\" %}\n\nCreate an application named `my-app` in the `my-dir` directory and use `scss` for styles:\n\n```bash\nnx g @nx/angular:app my-app --directory=my-dir --style=scss\n```\n\n{% /tab %}\n\n{% tab label=\"Single File Components application\" %}\n\nCreate an application with Single File Components (inline styles and inline templates):\n\n```bash\nnx g @nx/angular:app my-app --inlineStyle --inlineTemplate\n```\n\n{% /tab %}\n\n{% tab label=\"Standalone Components application\" %}\n\nCreate an application that is setup to use standalone components:\n\n```bash\nnx g @nx/angular:app my-app --standalone\n```\n\n{% /tab %}\n\n{% tab label=\"Set custom prefix and tags\" %}\n\nSet the prefix to apply to generated selectors and add tags to the application (used for linting).\n\n```bash\nnx g @nx/angular:app my-app --prefix=admin --tags=scope:admin,type:ui\n```\n\n{% /tab %}\n{% /tabs %}\n",
"description":"Change the Storybook target executors.",
"type":"object",
"cli":"nx",
"properties":{
"skipFormat":{
"description":"Skip formatting files.",
"type":"boolean",
"default":false,
"x-priority":"internal"
}
},
"additionalProperties":false,
"required":[],
"examplesFile":"This generator will change the `storybook` and `build-storybook` targets in all your Angular projects that are configured to use Storybook. The new target configuration will use the native Storybook builders (`@storybook/angular:build-storybook` and `@storybook/angular:start-storybook`) instead of the Nx Storybook builders (`@nrwl/storybook:build-storybook` and `@nrwl/storybook:storybook`).\n\nThis generator is usually invoked through a migrator, when you are using `nx migrate` to upgrade your workspace to Nx `14.1.8` or later.\n\nIf you are on Nx `14.1.8` or later and you did not use `nx migrate`, you can run this generator manually by running the following command:\n\n```bash\nnx g @nrwl/angular:change-storybook-targets\n```\n\nYou can read more about how this generator works, and why we are changing the Storybook targets, in the [Angular Storybook targets documentation page](/packages/storybook/documents/angular-storybook-targets).\n",
"presets":[]
},
"description":"Change storybook targets for Angular projects to use @storybook/angular executors",
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\n\nCreate a cypress spec for a component that is set up with Storybook.\n\n```bash\nnx g @nrwl/angular:component-cypress-spec --componentName=MyButtonComponent --componentPath=libs/ui/src/lib/button/button.component.ts --componentFileName=button.component --projectName=ui --projectPath=libs/ui\n```\n\n{% /tab %}\n\n{% /tabs %}\n",
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\n\nCreate a cypress spec for a component that is set up with Storybook.\n\n```bash\nnx g @nx/angular:component-cypress-spec --componentName=MyButtonComponent --componentPath=libs/ui/src/lib/button/button.component.ts --componentFileName=button.component --projectName=ui --projectPath=libs/ui\n```\n\n{% /tab %}\n\n{% /tabs %}\n",
"presets":[]
},
"description":"Creates a Cypress spec for a UI component that has a story.",
"description":"The name of the project where the component is located.",
"$default":{"$source":"projectName"},
"x-dropdown":"projects",
"x-prompt":"What project is the component located in?",
"x-priority":"important"
@@ -50,7 +51,7 @@
"componentDir",
"componentFileName"
],
"examplesFile":"{% callout type=\"caution\" title=\"Can I use component testing?\" %}\nAngular component testing with Nx requires **Cypress version 10.7.0** and up.\n\nYou can migrate with to v10 via the [migrate-to-cypress-10 generator](/packages/cypress/generators/migrate-to-cypress-10).\n\nThis generator is for Cypress based component testing.\n\nIf you're wanting to create Cypress tests for a Storybook story, then check out the [component-cypress-spec generator docs](/packages/angular/generators/component-cypress-spec)\n\nIf you're wanting to create Storybook stories for a component, then check out the [stories generator docs](/packages/angular/generators/stories) or [component-story generator docs](/packages/angular/generators/component-cypress-spec)\n{% /callout %}\n\nThis generator is used to create a Cypress component test file for a given Angular component.\n\n```shell\nnx g @nrwl/angular:component-test --project=my-cool-angular-project --componentName=CoolBtnComponent --componentDir=src/cool-btn --componentFileName=cool-btn.component\n```\n\nTest file are generated with the `.cy.ts` suffix. this is to prevent colliding with any existing `.spec.` files contained in the project.\n\nIt's currently expected the generated `.cy.ts` file will live side by side with the component. It is also assumed the project is already setup for component testing. If it isn't, then you can run the [cypress-component-project generator](/packages/angular/generators/cypress-component-configuration) to set up the project for component testing.\n",
"examplesFile":"{% callout type=\"caution\" title=\"Can I use component testing?\" %}\nAngular component testing with Nx requires **Cypress version 10.7.0** and up.\n\nYou can migrate with to v10 via the [migrate-to-cypress-10 generator](/packages/cypress/generators/migrate-to-cypress-10).\n\nThis generator is for Cypress based component testing.\n\nIf you're wanting to create Cypress tests for a Storybook story, then check out the [component-cypress-spec generator docs](/packages/angular/generators/component-cypress-spec)\n\nIf you're wanting to create Storybook stories for a component, then check out the [stories generator docs](/packages/angular/generators/stories) or [component-story generator docs](/packages/angular/generators/component-cypress-spec)\n{% /callout %}\n\nThis generator is used to create a Cypress component test file for a given Angular component.\n\n```shell\nnx g @nx/angular:component-test --project=my-cool-angular-project --componentName=CoolBtnComponent --componentDir=src/cool-btn --componentFileName=cool-btn.component\n```\n\nTest file are generated with the `.cy.ts` suffix. this is to prevent colliding with any existing `.spec.` files contained in the project.\n\nIt's currently expected the generated `.cy.ts` file will live side by side with the component. It is also assumed the project is already setup for component testing. If it isn't, then you can run the [cypress-component-project generator](/packages/angular/generators/cypress-component-configuration) to set up the project for component testing.\n",
"presets":[]
},
"description":"Creates a cypress component test file for a component.",
"x-prompt":"What name would you like to use for the component?"
},
"prefix":{
"type":"string",
"description":"The prefix to apply to the generated component selector.",
"alias":"p"
},
"displayBlock":{
"description":"Specifies if the style will contain `:host { display: block; }`.",
"type":"boolean",
@@ -47,7 +52,7 @@
"alias":"t"
},
"standalone":{
"description":"Whether the generated component is standalone. _Note: This is only supported in Angular versions >= 14.1.0_",
"description":"Whether the generated component is standalone. _Note: This is only supported in Angular versions >= 14.1.0_.",
"type":"boolean",
"default":false,
"x-priority":"important"
@@ -111,10 +116,16 @@
"description":"Specifies if the component should be exported in the declaring `NgModule`. Additionally, if the project is a library, the component will be exported from the project's entry point (normally `index.ts`) if the module it belongs to is also exported or if the component is standalone.",
"default":false,
"x-priority":"important"
},
"skipFormat":{
"description":"Skip formatting files.",
"type":"boolean",
"default":false,
"x-priority":"internal"
}
},
"required":["name"],
"examplesFile":"## Examples\n\n{% tabs %}\n{% tab label=\"Simple Component\" %}\n\nCreate a component named `my-component`:\n\n```bash\nnx g @nrwl/angular:component my-component\n```\n\n{% /tab %}\n\n{% tab label=\"Standalone Component\" %}\n\nCreate a standalone component named `my-component`:\n\n```bash\nnx g @nrwl/angular:component my-component --standalone\n```\n\n{% /tab %}\n\n{% tab label=\"Single File Component\" %}\n\nCreate a component named `my-component` with inline styles and inline template:\n\n```bash\nnx g @nrwl/angular:component my-component --inlineStyle --inlineTemplate\n```\n\n{% /tab %}\n\n{% tab label=\"Component with OnPush Change Detection Strategy\" %}\n\nCreate a component named `my-component` with OnPush Change Detection Strategy:\n\n```bash\nnx g @nrwl/angular:component my-component --changeDetection=OnPush\n```\n\n{% /tab %}\n",
"required":["name","project"],
"examplesFile":"## Examples\n\n{% tabs %}\n{% tab label=\"Simple Component\" %}\n\nCreate a component named `my-component`:\n\n```bash\nnx g @nx/angular:component my-component\n```\n\n{% /tab %}\n\n{% tab label=\"Standalone Component\" %}\n\nCreate a standalone component named `my-component`:\n\n```bash\nnx g @nx/angular:component my-component --standalone\n```\n\n{% /tab %}\n\n{% tab label=\"Single File Component\" %}\n\nCreate a component named `my-component` with inline styles and inline template:\n\n```bash\nnx g @nx/angular:component my-component --inlineStyle --inlineTemplate\n```\n\n{% /tab %}\n\n{% tab label=\"Component with OnPush Change Detection Strategy\" %}\n\nCreate a component named `my-component` with OnPush Change Detection Strategy:\n\n```bash\nnx g @nx/angular:component my-component --changeDetection=OnPush\n```\n\n{% /tab %}\n",
"description":"The name of the project to add cypress component testing configuration to",
"$default":{"$source":"projectName"},
"x-dropdown":"projects",
"x-prompt":"What project should we add Cypress component testing to?",
"x-priority":"important"
@@ -36,7 +37,7 @@
}
},
"required":["project"],
"examplesFile":"{% callout type=\"caution\" title=\"Can I use component testing?\" %}\nAngular component testing with Nx requires **Cypress version 10.7.0** and up.\n\nYou can migrate with to v10 via the [migrate-to-cypress-10 generator](/packages/cypress/generators/migrate-to-cypress-10).\n\nThis generator is for Cypress based component testing.\n\nIf you want to test components via Storybook with Cypress, then check out the [storybook-configuration generator docs](/packages/angular/generators/storybook-configuration)\n{% /callout %}\n\nThis generator is designed to get your Angular project up and running with Cypress Component Testing.\n\n```shell\nnx g @nrwl/angular:cypress-component-configuration --project=my-cool-angular-project\n```\n\nRunning this generator, adds the required files to the specified project with a preconfigured `cypress.config.ts` designed for Nx workspaces.\n\n```ts {% fileName=\"cypress.config.ts\" %}\nimport { defineConfig } from 'cypress';\nimport { nxComponentTestingPreset } from '@nrwl/angular/plugins/component-testing';\n\nexport default defineConfig({\n component: nxComponentTestingPreset(__filename),\n});\n```\n\nHere is an example on how to add custom options to the configuration\n\n```ts {% fileName=\"cypress.config.ts\" %}\nimport { defineConfig } from 'cypress';\nimport { nxComponentTestingPreset } from '@nrwl/angular/plugins/component-testing';\n\nexport default defineConfig({\n component: {\n ...nxComponentTestingPreset(__filename),\n // extra options here\n },\n});\n```\n\n## Specifying a Build Target\n\nComponent testing requires a _build target_ to correctly run the component test dev server. This option can be manually specified with `--build-target=some-angular-app:build`, but Nx will infer this usage from the [project graph](/concepts/mental-model#the-project-graph) if one isn't provided.\n\nFor Angular projects, the build target needs to be using the `@nrwl/angular:webpack-browser` or\n`@angular-devkit/build-angular:browser` executor.\nThe generator will throw an error if a build target can't be found and suggest passing one in manually.\n\nLetting Nx infer the build target by default\n\n```shell\nnx g @nrwl/angular:cypress-component-configuration --project=my-cool-angular-project\n```\n\nManually specifying the build target\n\n```shell\nnx g @nrwl/angular:cypress-component-configuration --project=my-cool-angular-project --build-target:some-angular-app:build --generate-tests\n```\n\n{% callout type=\"note\" title=\"Build Target with Configuration\" %}\nIf you're wanting to use a build target with a specific configuration. i.e. `my-app:build:production`,\nthen manually providing `--build-target=my-app:build:production` is the best way to do that.\n{% /callout %}\n\n## Auto Generating Tests\n\nYou can optionally use the `--generate-tests` flag to generate a test file for each component in your project.\n\n```shell\nnx g @nrwl/angular:cypress-component-configuration --project=my-cool-angular-project --generate-tests\n```\n\n## Running Component Tests\n\nA new `component-test` target will be added to the specified project to run your component tests.\n\n```shell\nnx g component-test my-cool-angular-project\n```\n\nHere is an example of the project configuration that is generated. The `--build-target` option is added as the `devServerTarget` which can be changed as needed.\n\n```json {% fileName=\"project.json\" %}\n{\n \"targets\" {\n \"component-test\": {\n \"executor\": \"@nrwl/cypress:cypress\",\n \"options\": {\n \"cypressConfig\": \"<path-to-project-root>/cypress.config.ts\",\n \"testingType\": \"component\",\n \"devServerTarget\": \"some-angular-app:build\",\n \"skipServe\": true\n }\n }\n }\n}\n```\n\nNx also supports [React component testing](/packages/angular/generators/cypress-component-configuration).\n",
"examplesFile":"{% callout type=\"caution\" title=\"Can I use component testing?\" %}\nAngular component testing with Nx requires **Cypress version 10.7.0** and up.\n\nYou can migrate with to v10 via the [migrate-to-cypress-10 generator](/packages/cypress/generators/migrate-to-cypress-10).\n\nThis generator is for Cypress based component testing.\n\nIf you want to test components via Storybook with Cypress, then check out the [storybook-configuration generator docs](/packages/angular/generators/storybook-configuration)\n{% /callout %}\n\nThis generator is designed to get your Angular project up and running with Cypress Component Testing.\n\n```shell\nnx g @nx/angular:cypress-component-configuration --project=my-cool-angular-project\n```\n\nRunning this generator, adds the required files to the specified project with a preconfigured `cypress.config.ts` designed for Nx workspaces.\n\n```ts {% fileName=\"cypress.config.ts\" %}\nimport { defineConfig } from 'cypress';\nimport { nxComponentTestingPreset } from '@nx/angular/plugins/component-testing';\n\nexport default defineConfig({\n component: nxComponentTestingPreset(__filename),\n});\n```\n\nHere is an example on how to add custom options to the configuration\n\n```ts {% fileName=\"cypress.config.ts\" %}\nimport { defineConfig } from 'cypress';\nimport { nxComponentTestingPreset } from '@nx/angular/plugins/component-testing';\n\nexport default defineConfig({\n component: {\n ...nxComponentTestingPreset(__filename),\n // extra options here\n },\n});\n```\n\n## Specifying a Build Target\n\nComponent testing requires a _build target_ to correctly run the component test dev server. This option can be manually specified with `--build-target=some-angular-app:build`, but Nx will infer this usage from the [project graph](/concepts/mental-model#the-project-graph) if one isn't provided.\n\nFor Angular projects, the build target needs to be using the `@nx/angular:webpack-browser` or\n`@angular-devkit/build-angular:browser` executor.\nThe generator will throw an error if a build target can't be found and suggest passing one in manually.\n\nLetting Nx infer the build target by default\n\n```shell\nnx g @nx/angular:cypress-component-configuration --project=my-cool-angular-project\n```\n\nManually specifying the build target\n\n```shell\nnx g @nx/angular:cypress-component-configuration --project=my-cool-angular-project --build-target:some-angular-app:build --generate-tests\n```\n\n{% callout type=\"note\" title=\"Build Target with Configuration\" %}\nIf you're wanting to use a build target with a specific configuration. i.e. `my-app:build:production`,\nthen manually providing `--build-target=my-app:build:production` is the best way to do that.\n{% /callout %}\n\n## Auto Generating Tests\n\nYou can optionally use the `--generate-tests` flag to generate a test file for each component in your project.\n\n```shell\nnx g @nx/angular:cypress-component-configuration --project=my-cool-angular-project --generate-tests\n```\n\n## Running Component Tests\n\nA new `component-test` target will be added to the specified project to run your component tests.\n\n```shell\nnx g component-test my-cool-angular-project\n```\n\nHere is an example of the project configuration that is generated. The `--build-target` option is added as the `devServerTarget` which can be changed as needed.\n\n```json {% fileName=\"project.json\" %}\n{\n \"targets\" {\n \"component-test\": {\n \"executor\": \"@nx/cypress:cypress\",\n \"options\": {\n \"cypressConfig\": \"<path-to-project-root>/cypress.config.ts\",\n \"testingType\": \"component\",\n \"devServerTarget\": \"some-angular-app:build\",\n \"skipServe\": true\n }\n }\n }\n}\n```\n\nNx also supports [React component testing](/packages/angular/generators/cypress-component-configuration).\n",
"presets":[]
},
"description":"Setup Cypress component testing for a project.",
"description":"Sets up a Downgrade Module for using AngularJS and Angular.",
"cli":"nx",
"type":"object",
"properties":{
"project":{
"type":"string",
"description":"The name of the project.",
"x-priority":"important"
},
"name":{
"type":"string",
"description":"The name of the main AngularJS module.",
"$default":{"$source":"argv","index":0},
"x-priority":"important"
},
"angularJsImport":{
"type":"string",
"description":"Import expression of the AngularJS application (e.g., `--angularJsImport=some_node_module/my_app`)."
},
"skipFormat":{
"type":"boolean",
"description":"Skip formatting files.",
"default":false,
"x-priority":"internal"
},
"skipPackageJson":{
"type":"boolean",
"description":"Do not add `@angular/upgrade` to `package.json` (e.g., `--skipPackageJson`).",
"default":false,
"x-priority":"internal"
}
},
"additionalProperties":false,
"required":["name","project"],
"examplesFile":"## Examples\n\nBelow are some examples of how to generate configuration and setup for using `ngUpgrade`'s `DowngradeModule` for your application.\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\n\n```bash\nnx g @nrwl/angular:downgrade-module --name=myAngularJsModule --project=myapp\n```\n\n{% /tab %}\n\n{% tab label=\"Setup Router\" %}\n\nAllow a setup that configures routing for `DowngradeModule`.\n\n```bash\nnx g @nrwl/angular:downgrade-module --name=myAngularJsModule --project=myapp --router=true\n```\n\n{% /tab %}\n\n{% /tabs %}\n",
"command":"nx g @nrwl/angular:host appName --remotes=remote1",
"command":"nx g @nx/angular:host appName --remotes=remote1",
"description":"Create an Angular application with configuration in place for Module Federation. If the `remotes` option is provided, attach the remote application to this application's configuration"
}
],
@@ -18,7 +18,8 @@
"name":{
"type":"string",
"description":"The name to give to the host Angular application.",
"$default":{"$source":"argv","index":0}
"$default":{"$source":"argv","index":0},
"pattern":"^[a-zA-Z].*$"
},
"remotes":{
"type":"array",
@@ -102,14 +103,15 @@
},
"unitTestRunner":{
"type":"string",
"enum":["karma","jest","none"],
"enum":["jest","none"],
"description":"Test runner to use for unit tests.",
"default":"jest"
},
"e2eTestRunner":{
"type":"string",
"enum":["protractor","cypress","none"],
"enum":["cypress","playwright","none"],
"description":"Test runner to use for end to end (E2E) tests.",
"x-prompt":"Which E2E test runner would you like to use?",
"title":"Create Karma Configuration for a project",
"description":"Add Karma configuration to an angular project.",
"cli":"nx",
"type":"object",
"properties":{
"project":{
"type":"string",
"description":"The name of the project.",
"x-dropdown":"projects",
"x-priority":"important"
},
"skipFormat":{
"description":"Skip formatting files.",
"type":"boolean",
"default":false,
"x-priority":"internal"
},
"skipPackageJson":{
"description":"Skip updating package.json.",
"type":"boolean",
"default":false,
"x-priority":"internal"
}
},
"additionalProperties":false,
"required":["project"],
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\n\nTo add karma to project, run the following command.\n\n```bash\nnx g @nrwl/angular:karma-project --project=myapp\n```\n\n{% /tab %}\n\n{% /tabs %}\n",
"presets":[]
},
"description":"Adds Karma configuration to a project.",
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\nCreate a secondary entrypoint named `button` in the `ui` library.\n\n```bash\nnx g @nrwl/angular:library-secondary-entry-point --library=ui --name=button\n```\n\n{% /tab %}\n\n{% tab label=\"Skip generating module\" %}\nCreate a secondary entrypoint named `button` in the `ui` library but skip creating an NgModule.\n\n```bash\nnx g @nrwl/angular:library-secondary-entry-point --library=ui --name=button --skipModule\n```\n\n{% /tab %}\n\n{% /tabs %}\n",
"examplesFile":"## Examples\n\n{% tabs %}\n\n{% tab label=\"Basic Usage\" %}\nCreate a secondary entrypoint named `button` in the `ui` library.\n\n```bash\nnx g @nx/angular:library-secondary-entry-point --library=ui --name=button\n```\n\n{% /tab %}\n\n{% tab label=\"Skip generating module\" %}\nCreate a secondary entrypoint named `button` in the `ui` library but skip creating an NgModule.\n\n```bash\nnx g @nx/angular:library-secondary-entry-point --library=ui --name=button --skipModule\n```\n\n{% /tab %}\n\n{% /tabs %}\n",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Max Kless