Building Angular Apps with the Nx Standalone Projects Setup

In this tutorial you'll learn how to use Angular with Nx in a "standalone" (non-monorepo) setup. Not to be confused with the "Angular Standalone API", a standalone project in Nx is a non-monorepo setup where you have a single application at the root level. This setup is very similar to what the Angular CLI gives you.

What are you going to learn?

• how to create a new standalone (single-project) Nx workspace setup for Angular
• how to run a single task (i.e. serve your app) or run multiple tasks in parallel
• how to leverage code generators to scaffold components
• how to modularize your codebase and impose architectural constraints for better maintainability

Final Code

Here's the source code of the final result for this tutorial.

Also, if you prefer learning with a video, join Juri and walk through the tutorial, step by step together.

Creating a new Angular App

Create a new Angular application with the following command:

You get asked a few questions that help Nx preconfigure your new Angular application. These include:

• Angular specific questions, such as which bundler to use, whether to enable server-side rendering and which stylesheet format to use
• General Nx questions, such as whether to enable remote caching with Nx Cloud. Nx comes with built-in local caching. If you want to benefit from this cache in CI, you can enable remote caching which will set up Nx Cloud. This is also a prerequisite for enabling distributed task execution.

For the sake of this tutorial, let's respond to all the questions with the default response.

The create-nx-workspace command generates the following structure:

The setup includes:

• a new Angular application at the root of the Nx workspace (src/app)
• a Cypress based set of e2e tests (e2e/)
• Prettier preconfigured
• ESLint & Angular ESLint preconfigured
• Jest preconfigured

Compared to the Angular CLI, you might notice the addition of an nx.json file and the absence of an angular.json file. Instead of the angular.json file there is a project.json file. Each file is described below:

Serving the App

The most common tasks are already defined in the package.json file:

To serve your new Angular application, just run: npm start. Alternatively you can directly use Nx by running:

Your application should be served at http://localhost:4200.

Nx uses the following syntax to run tasks:

Manually Defined Tasks

The project tasks are defined in the project.json file:

Each target contains a configuration object that tells Nx how to run that target.

The most critical parts are:

• executor - This corresponds to the builder property in an Angular CLI workspace. You can use Angular builders or executors from Nx plugins.
• options - these are additional properties and flags passed to the executor function to customize it

Learn more about how to run tasks with Nx.

Testing and Linting

Our current setup not only has targets for serving and building the Angular application, but also has targets for unit testing, e2e testing and linting. The test and lint targets are defined in the application project.json file, while the e2e target is inferred from the e2e/cypress.config.ts file. We can use the same syntax as before to run these tasks:

Inferred Tasks

Nx identifies available tasks for your project from tooling configuration files, package.json scripts and the targets defined in project.json. All tasks from the myngapp project are defined in its project.json file, but the companion e2e project has its tasks inferred from configuration files. To view the tasks that Nx has detected, look in the Nx Console, Project Details View or run:

If you expand the e2e task, you can see that it was created by the @nx/cypress plugin by analyzing the e2e/cypress.config.ts file. Notice the outputs are defined as:

This value is being read from the videosFolder and screenshotsFolder defined by the nxE2EPreset in your e2e/cypress.config.ts file. Let's change their value in your e2e/cypress.config.ts file:

Now if you look at the project details view again, the outputs for the e2e target will be:

This feature ensures that Nx will always cache the correct files.

You can also override the settings for inferred tasks by modifying the targetDefaults in nx.json or setting a value in your project.json file. Nx will merge the values from the inferred tasks with the values you define in targetDefaults and in your specific project's configuration.

Running Multiple Tasks

In addition to running individual tasks, you can also run multiple tasks in parallel using the following syntax:

Caching

One thing to highlight is that Nx is able to cache the tasks you run.

Note that all of these targets are automatically cached by Nx. If you re-run a single one or all of them again, you'll see that the task completes immediately. In addition, (as can be seen in the output example below) there will be a note that a matching cache result was found and therefore the task was not run again.

Not all tasks might be cacheable though. You can configure the cache properties in the targets under targetDefaults in the nx.json file. You can also learn more about how caching works.

Creating New Components

Similar to the Angular CLI, Nx comes with code generation abilities. What the Angular CLI calls "Schematics", Nx calls "Generators".

Generators allow you to easily scaffold code, configuration or entire projects. To see what capabilities the @nx/angular plugin ships with, run the following command and inspect the output:

Run the following command to generate a new "hello-world" component. Note how we append --dry-run to first check the output.

As you can see it generates a new component in the app/hello-world/ folder. If you want to actually run the generator, remove the --dry-run flag.

Building the App for Deployment

If you're ready and want to ship your application, you can build it using

All the required files will be placed in the dist/myngapp folder and can be deployed to your favorite hosting provider.

You're ready to go!

In the previous sections you learned about the basics of using Nx, running tasks and navigating an Nx workspace. You're ready to ship features now!

But there's more to learn. You have two possibilities here:

• Jump to the next steps section to find where to go from here or
• keep reading and learn some more about what makes Nx unique when working with Angular.

Modularizing your Angular App with Local Libraries

When you develop your Angular application, usually all your logic sits in the app folder. Ideally separated by various folder names which represent your "domains". As your app grows, this becomes more and more monolithic though.

The following structure is a common example of this kind of monolithic code organization:

Nx allows you to separate this logic into "local libraries". The main benefits include

• better separation of concerns
• better reusability
• more explicit "APIs" between your "domain areas"
• better scalability in CI by enabling independent test/lint/build commands for each library
• better scalability in your teams by allowing different teams to work on separate libraries

Creating Local Libraries

Let's assume our domain areas include products, orders and some more generic design system components, called ui. We can generate a new library for each of these areas using the Angular library generator:

Note how we use the --directory flag to place the libraries into a subfolder. You can choose whatever folder structure you like, even keep all of them at the root-level.

Running the above commands should lead to the following directory structure:

Each of these libraries

• has its own project.json file with corresponding targets you can run (e.g. running tests for just orders: nx test orders)
• has a dedicated index.ts file which is the "public API" of the library
• is mapped in the tsconfig.base.json at the root of the workspace

Importing Libraries into the Angular Application

All libraries that we generate automatically have aliases created in the root-level tsconfig.base.json.

Hence we can easily import them into other libraries and our Angular application. For example: let's use our existing ProductsComponent in modules/products/src/lib/products/:

Make sure the ProductsComponent is exported via the index.ts file of our products library (which it should already be). The modules/products/src/index.ts file is the public API for the products library with the rest of the workspace. Only export what's really necessary to be usable outside the library itself.

We're ready to import it into our main application now. If you opted into generating a router configuration when setting up the Nx workspace initially, you should have an app.routes.ts file in your app folder. If not, create it and configure the Angular router.

Configure the routing as follows:

As part of this step, we should also remove the NxWelcomeComponent from the AppComponent.imports declaration so that it is just loaded over the routing mechanism. The app.component.html should just have the <router-outlet> left:

If you now navigate to http://localhost:4200/products you should see the ProductsComponent being rendered.

Let's do the same process for our orders library. Import the OrdersComponent into the app.routes.ts:

Similarly, navigating to http://localhost:4200/orders should now render the OrdersComponent.

A couple of notes:

• both the ProductsComponent and OrdersComponent are lazy loaded
• you could go even further and configure routes within the libraries and only import and attach those routes to the application routing mechanism.

Visualizing your Project Structure

Nx automatically detects the dependencies between the various parts of your workspace and builds a project graph. This graph is used by Nx to perform various optimizations such as determining the correct order of execution when running tasks like nx build, identifying affected projects and more. Interestingly you can also visualize it.

Just run:

You should be able to see something similar to the following in your browser (hint: click the "Show all projects" button).

Notice how shared-ui is not yet connected to anything because we didn't import it in any of our projects. Also the arrows to orders and products are dashed because we're using lazy imports.

Exercise for you: change the codebase so that shared-ui is used by orders and products. Note: you need to restart the nx graph command to update the graph visualization or run the CLI command with the --watch flag.

Imposing Constraints with Module Boundary Rules

Once you modularize your codebase you want to make sure that the modules are not coupled to each other in an uncontrolled way. Here are some examples of how we might want to guard our small demo workspace:

• we might want to allow orders to import from shared-ui but not the other way around
• we might want to allow orders to import from products but not the other way around
• we might want to allow all libraries to import the shared-ui components, but not the other way around

When building these kinds of constraints you usually have two dimensions:

• type of project: what is the type of your library. Example: "feature" library, "utility" library, "data-access" library, "ui" library (see library types)
• scope (domain) of the project: what domain area is covered by the project. Example: "orders", "products", "shared" ... this really depends on the type of product you're developing

Nx comes with a generic mechanism that allows you to assign "tags" to projects. "tags" are arbitrary strings you can assign to a project that can be used later when defining boundaries between projects. For example, go to the project.json of your orders library and assign the tags type:feature and scope:orders to it.

Then go to the project.json of your products library and assign the tags type:feature and scope:products to it.

Finally, go to the project.json of the shared-ui library and assign the tags type:ui and scope:shared to it.

Notice how we assign scope:shared to our UI library because it is intended to be used throughout the workspace.

Next, let's come up with a set of rules based on these tags:

• type:feature should be able to import from type:feature and type:ui
• type:ui should only be able to import from type:ui
• scope:orders should be able to import from scope:orders, scope:shared and scope:products
• scope:products should be able to import from scope:products and scope:shared

To enforce the rules, Nx ships with a custom ESLint rule. Open the .eslintrc.base.json at the root of the workspace and add the following depConstraints in the @nx/enforce-module-boundaries rule configuration:

To test it, go to your modules/products/src/lib/products/products.component.ts file and import the OrderComponent from the orders project:

If you lint your workspace you'll get an error now:

If you have the ESLint plugin installed in your IDE you should immediately see an error:

Learn more about how to enforce module boundaries.

Migrating to a Monorepo

When you are ready to add another application to the repo, you'll probably want to move myngapp to its own folder. To do this, you can run the convert-to-monorepo generator or manually move the configuration files.

You can also go through the full Angular monorepo tutorial

Set Up CI for the Angular App

This tutorial walked you through how Nx can improve the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.

• Nx reduces wasted time in CI with the affected command.
• Nx Replay's remote caching will reuse task artifacts from different CI executions making sure you will never run the same computation twice.
• Nx Agents efficiently distribute tasks across machines ensuring constant CI time regardless of the repository size. The right number of machines is allocated for each PR to ensure good performance without wasting compute.
• Nx Atomizer automatically splits large e2e tests to distribute them across machines. Nx can also automatically identify and rerun flaky e2e tests.

Generate a CI Workflow

If you are starting a new project, you can use the following command to generate a CI workflow file.

This generator creates a .github/workflows/ci.yml file that contains a CI pipeline that will run the lint, test, build and e2e tasks for projects that are affected by any given PR.

The key line in the CI pipeline is:

Connect to Nx Cloud

Nx Cloud is a companion app for your CI system that provides remote caching, task distribution, e2e tests deflaking, better DX and more.

To connect to Nx Cloud:

• Commit and push your changes
• Go to https://cloud.nx.app, create an account, and connect your repository

Connect to Nx Cloud Manually

If you are not able to connect via the automated process at https://cloud.nx.app, you can connect your workspace manually by running:

You will then need to merge your changes and connect to your workspace on https://cloud.nx.app.

Enable a Distributed CI Pipeline

The current CI pipeline runs on a single machine and can only handle small workspaces. To transform your CI into a CI that runs on multiple machines and can handle workspaces of any size, uncomment the npx nx-cloud start-ci-run line in the .github/workflows/ci.yml file.

For more information about how Nx can improve your CI pipeline, check out one of these detailed tutorials:

• Circle CI with Nx
• GitHub Actions with Nx

Next Steps

Here's some things you can dive into next:

• Learn more about the underlying mental model of Nx
• Learn about popular generators such as how to setup Tailwind or add Storybook to your UI library
• Learn how to migrate your existing Angular CLI repo to Nx

Also, make sure you

• Join the Official Nx Discord Server to ask questions and find out the latest news about Nx.
• Follow Nx on Twitter to stay up to date with Nx news
• Read our Nx blog
• Subscribe to our Youtube channel for demos and Nx insights