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, ESLint, Tailwind CSS, Cypress, Karma, and Protractor. 

- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) 

- Upgrading AngularJS applications 

- Single Component Application Modules (SCAMs) 

- NgRx helpers. 

- Utilities for automatic workspace refactoring.

![Angular logo](/shared/angular-logo.png)

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.
- Generators to help scaffold code quickly, including:
  - Micro Frontends
  - Libraries, both internal to your codebase and publishable to npm
  - Upgrading AngularJS applications
  - Single Component Application Modules (SCAMs)
- NgRx helpers.
- 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](/recipe/migration-angular).
{% /callout %}

## Setting up the Angular plugin

Adding the Angular plugin to an existing Nx workspace can be done with the following:

```bash
yarn add -D @nrwl/angular
```

```bash
npm install -D @nrwl/angular
```

## Using the Angular Plugin

### Generating an application

It's straightforward to generate an Angular application:

```bash
nx g @nrwl/angular:app appName
```

By default, the application will be generated with:

- ESLint as the linter.
- Jest as the unit test runner.
- Cypress as the E2E test runner.

We can then serve, build, test, lint, and run e2e tests on the application with the following commands:

```bash
nx serve appName
nx build appName
nx test appName
nx lint appName
nx e2e appName
```

### Generating a library

Generating an Angular library is very similar to generating an application:

```bash
nx g @nrwl/angular:lib libName
```

By default, the library will be generated with:

- ESLint as the linter.
- Jest as the unit test runner.

We can then test and lint the library with the following commands:

```bash
nx test libName
nx lint libName
```

Read more about:

- [Creating Libraries](/more-concepts/creating-libraries)
- [Library Types](/more-concepts/library-types)
- [Buildable and Publishable Libraries](/more-concepts/buildable-and-publishable-libraries)

## More Documentation

- [Angular Nx Tutorial](/angular-tutorial/01-create-application)
- [Migrating from the Angular CLI](recipe/migration-angular)
- [Setup Module Federation with Angular and Nx](/recipe/faster-builds)
- [Using NgRx](/recipe/misc-ngrx)
- [Using Data Persistence operators](/recipe/misc-data-persistence)
- [Upgrading an AngularJS application to Angular](/recipe/migration-angularjs)
- [Using Tailwind CSS with Angular projects](/recipe/using-tailwind-css-with-angular-projects)


Overview

# 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)_ |
| --------------- | ------------------------------ | -------------------- |
| ^8.0.0          | **8.12.2**                     | 8.7.0 <= 8.12.2      |
| ^9.0.0          | **9.6.0**                      | 8.12.4 <= 9.6.0      |
| ^10.0.0         | **10.4.15**                    | 9.7.0 <= 10.4.15     |
| ^11.0.0         | **12.2.0**                     | 11.0.0 <= 12.2.0     |
| ^12.0.0         | **13.1.4**                     | 12.3.0 <= 13.1.4     |
| ^13.0.0         | **14.1.9**                     | .13.2.0 <= 14.1.9    |
| ~14.0.0         | **14.4.3**                     | 14.2.1 <= 14.4.3     |
| ~14.1.0         | **14.5.10**                    | 14.5.0 <= 14.5.10    |
| ~14.2.0         | **14.6.0**                     | 14.6.0 <= latest     |

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).


Angular and Nx Version Matrix

Delegates the build to a different target while supporting incremental builds.

delegate-build

Options for delegating a build to a different target.

Build target used for building the application after its dependencies have been built.

The full path for the output directory, relative to the workspace root.

The full path for the TypeScript configuration file, relative to the workspace root.

Whether to run a build when any file changes.

Schema for an executor which delegates a build.

Builds a library with support for incremental builds.

ng-packagr-lite

ng-packagr target options for Build Architect. Use to build library projects.

Buildable Library with Tailwind

Updating Project Dependencies for Buildable Library

When `updateBuildableProjectDepsInPackageJson` is `true`, this adds dependencies to either `peerDependencies` or `dependencies`.

The file path for the ng-packagr configuration file, relative to the workspace root.

The full path for the Tailwind configuration file, relative to the workspace root. If not provided and a `tailwind.config.js` file exists in the project or workspace root, it will be used. Otherwise, Tailwind will not be configured.

Whether to update the buildable project dependencies in package.json.

ng-packagr Target

Builds and packages an Angular library to be distributed as an NPM package. It supports incremental builds.

package

ng-packagr target options for Build Architect. Use to build and package library projects for publishing.

Publishable Library with Tailwind

Updating Project Dependencies for Publishable Library

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:   
- Supports Custom Webpack Configurations  
- Supports Incremental Building

webpack-browser

The threshold for error relative to the baseline (min & max).

The maximum threshold for error relative to the baseline.

The maximum threshold for warning relative to the baseline.

The minimum threshold for error relative to the baseline.

The minimum threshold for warning relative to the baseline.

The threshold for warning relative to the baseline (min & max).

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:   
- Supports Custom Webpack Configurations  
- Supports Incremental Building

Custom Webpack Configuration

A list of CommonJS packages that are allowed to be used without a build time warning.

Base url for the application being built.

Budget thresholds to ensure parts of your application stay within boundaries which you set.

Read buildable libraries from source instead of building them separately.

Enables advanced build optimizations when using the 'aot' option.

Generate a seperate bundle containing code used across multiple bundles.

Define the crossorigin attribute setting of elements that provide CORS support.

Options for additional webpack configurations.

Path to additional webpack configuration, relative to the workspace root.

Replace compilation source files with other compilation source files in the build.

How to handle duplicate translations for i18n.

How to handle missing translations for i18n.

Configures the generation of the application's HTML index.

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.

The stylesheet language to use for the application's inline component styles.

Translate the bundles in one or more locales.

The full path for the main entry point to the app, relative to the current workspace.

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.

Define the output filename cache-busting hashing mode.

The full path for the new output directory, relative to the current workspace.

By default, writes output to a folder named dist/ in the current project.

Enable and define the file watching poll time period in milliseconds.

The full path for the polyfills file, relative to the current workspace.

Do not use the real path when resolving modules. If unset then will default to `true` if NodeJS option --preserve-symlinks is set.

Log progress to the console while building.

The path where style resources will be placed, relative to outputPath.

Global scripts to be included in the build.

Generates a service worker config for production builds.

Output source maps for scripts and styles. For more information, see https://angular.io/guide/workspace-config#source-map-configuration.

Generates a 'stats.json' file which can be analyzed using tools such as 'webpack-bundle-analyzer'.

Paths to include. Paths will be resolved to project root.

Enables the use of subresource integrity validation.

The full path for the TypeScript configuration file, relative to the current workspace.

Generate a seperate bundle containing only vendor libraries. This option should only used for development.

TypeScript configuration for Web Worker modules.

Schema for Webpack Browser

The `webpack-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.

webpack-server

The webpack-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.

Using a Different Port

List of hosts that are allowed to access the dev server.

A browser builder target to serve in the format of `project:target[:configuration]`. You can also pass in more than one configuration name as a comma-separated list. Example: `project:target:production,staging`.

Read buildable libraries from source instead of building them separately. If not set, it will take the value specified in the `browserTarget` options, or it will default to `true` if it's also not set in the `browserTarget` options.

Don't verify connected clients are part of allowed hosts.

Custom HTTP headers to be added to all responses.

Whether to reload the page on change, using live-reload.

Proxy configuration file. For more information, see https://angular.io/guide/build#proxying-to-a-backend-server.

The URL that the browser client (or live-reload client, if enabled) should use to connect to the development server. Use for a complex dev server setup, such as one with reverse proxies.

The pathname where the app will be served.

SSL certificate to use for serving HTTPS.

Schema for Webpack Server

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.

module-federation-dev-server

List of remote applications to run in development mode (i.e. using serve target).

Schema for Module Federation Dev Server

file-server

Options for the proxy used by `http-server`.

Redirect 404 errors to index.html (useful for SPA's).

SSL certificate to use for serving `HTTPS`.

File Server

Adds linting configuration to an Angular project.

add-linting

The prefix to apply to generated selectors.

The path to the root of the selected project.

Whether or not to configure the ESLint `parserOptions.project` option. We do not do this by default for lint performance reasons.

Do not add dependencies to `package.json`.

Add linting to an Angular project.

application

Whether to configure Tailwind CSS for the application.

Backend project that provides data to this application. This sets up `proxy.config.json`.

Test runner to use for end to end (E2E) tests. The `protractor` option is deprecated and it will be removed in v15.

Specifies if the style will be in the ts file.

Specifies if the template will be in the ts file.

The port at which the remote application should be served.

Skip setting the project as the default project. When `false` (the default), the project is set as the default project only if there is no default project already set.

Do not add or append `ngcc` to the `postinstall` script in `package.json`.

Generate an application that is setup to use standalone components.

Split the project configuration into `<projectRoot>/project.json` rather than including it inside `workspace.json`.

Create an application with stricter type checking and build optimization options.

Specifies the view encapsulation strategy.

Creates an Angular application.

component

Creates a new, generic Angular component definition in the given or default project.

The change detection strategy to use in the new component.

Specifies if the style will contain `:host { display: block; }`.

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.

Create the new files at the top level of the current project.

Include styles inline in the component.ts file. Only CSS styles can be included inline. By default, an external styles file is created and referenced in the component.ts file.

Include template inline in the component.ts file. By default, an external template file is created and referenced in the component.ts file.

The filename or path to the NgModule that will declare this component.

The path at which to create the component file, relative to the current workspace. Default is a folder with the same name as the component in the project root.

The HTML selector to use for this component.

Do not import this component into the owning NgModule.

Specifies if the component should have a selector or not.

Do not create `spec.ts` test files for the new component.

Whether the generated component is standalone.

Adds a developer-defined type to the filename, in the format `name.type.ts`.

The view encapsulation strategy to use in the new component.

Angular Component Schema

Creates a Cypress spec for a UI component that has a story.

component-cypress-spec

Component file name without the `.ts` extension.

Relative path to the component file from the project root.

The Cypress project to generate the stories under. By default, inferred from `projectName`.

Directory where to place the generated spec file. By default matches the value of the `componentPath` option.

Creates a stories.ts file for a component.

component-story

Creates a `stories.ts` file for an Angular component.

Creates a cypress component test file for a component.

component-test

Create a `*.cy.ts` file for Cypress component testing for an Angular component.

Relative path to the folder that contains the component from the project root.

File name that contains the component without the `.ts` extension.

Class name of the component to create a test for.

The name of the project where the component is located.

Converts a project from TSLint to ESLint.

convert-tslint-to-eslint

Convert an Angular project from TSLint to ESLint. NOTE: Does not work in `--dry-run mode`.

The following will first configure the project, `myapp`, the same way a _new_ project is configured i.e. It will use Nx's new recommended ESLint config. By default, this also adds the existing TSLint configuration on top of the default ESLint config from Nx to continue checking what it checks today. This is done by migrating TSLint rules to their equivalent ESLint rules to the best of its abilities. Some TSLint rules may not have ESLint equivalents and will be reported during the conversion

If your TSLint config isn't extremely important to you, ignoring it makes this process more deterministic. Unlike the prior example, this will discard the existing TSLint configuration, meaning that the project will only have the Nx's latest recommended ESLint configuration which may be good enough for some workspaces

By default, this process removes the TSLint related dependencies and configuration once no more projects use TSLint. This can be disabled with the following flag to keep TSLint related dependencies and configuration in the repo

If true, it will not use existing TSLint config as a reference, it will just reset the project with the latest recommended ESLint config.

The name of the Angular project to convert. Please note, if the project is an Angular app with an associated Cypress e2e project, it will also attempt to convert that.

If this conversion leaves no more TSLint usage in the workspace, it will remove TSLint and related dependencies and configuration.

Convert an Angular project from TSLint to ESLint

downgrade-module

Sets up a Downgrade Module for using AngularJS and Angular.

Import expression of the AngularJS application (e.g., `--angularJsImport=some_node_module/my_app`).

Do not add `@angular/upgrade` to `package.json` (e.g., `--skipPackageJson`).

Generates downgradeModule setup.

init

Initializes the `@nrwl/angular` plugin. NOTE: Does not work in the `--dry-run` mode.

Test runner to use for end to end (e2e) tests.

Skip installing after adding `@nrwl/workspace`.

Init Angular Plugin

karma

Add Karma configuration to an Nx workspace.

Add Karma Configuration to the workspace.

karma-project

Add Karma configuration to an angular project.

Create Karma Configuration for a project

library

Whether to configure Tailwind CSS for the application. It can only be used with buildable and publishable libraries. Non-buildable libraries will use the application's Tailwind configuration.

The change detection strategy to use in the new component. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Specifies the compilation mode to use. If not specified, it will default to `partial` for publishable libraries and to `full` for buildable libraries. The `full` value can not be used for publishable libraries.

Specifies if the component generated style will contain `:host { display: block; }`. Disclaimer: This option is only valid when `--standalone` is set to `true`.

The library name used to import it, like `@myorg/my-awesome-lib`. Must be a valid npm name.

Include styles inline in the component.ts file. Only CSS styles can be included inline. By default, an external styles file is created and referenced in the component.ts file. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Include template inline in the component.ts file. By default, an external template file is created and referenced in the component.ts file. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Add `RouterModule.forChild` when set to true, and a simple array of routes when set to false.

Path to the parent route configuration using `loadChildren` or `children`, depending on what `lazy` is set to.

Add router configuration. See `lazy` for more information.

The HTML selector to use for this component. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Keep the module name simple (when using `--directory`).

Whether to skip the creation of a default module when generating the library.

Specifies if the component should have a selector or not. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Do not create `spec.ts` test files for the new component. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Do not update `tsconfig.json` for development experience.

Generate a library that uses a standalone component instead of a module as the entry point.

Create a library with stricter type checking and build optimization options.

The view encapsulation strategy to use in the new component. Disclaimer: This option is only valid when `--standalone` is set to `true`.

Create a library

Creates a secondary entry point for an Angular publishable library.

@nrwl/angular:karma

Usage

Options

skipPackageJson