Introduction to the Building Angular applications with NX

Speaker introduction and course overview

What is NX?

Difference between Repository and Monorepo

Repository vs Monorepo

Angular and NX - Why?

Advantages of NX

Disadvantages of NX

First module summary

Introduction

Second module introduction

Short lesson about NX installation methods

NX installation

A quick overview of the default suggested directory structure of NX repository.

NX repository folder layout

Second module summary

How to install NX

How to build a simple application and how to create libraries in NX

Third module introduction

Adding the first app

Adding the first library

Code session for the first application and library in NX.

Time tracker code

Third module summary

The first NX Angular application

What else you can keep in monorepo...? Multiple apps using multiple frameworks, built-in Storybook and Cypress configuration

Fourth module introduction

How can you add more apps to monorepo, which frameworks are available at the time, and advantages of keeping them together

Built-in app types in NX

What are buildable and publishable libraries

Built-in library types in NX

Storybook

End-to-end testing

Fourth module summary

More built-in NX features

This module will present a real-life example of an NX mono repository with multiple libraries and three applications.

Fifth module introduction

Presenting the current module's plan, highlighting crucial backend details for the frontend to illustrate the problem domain.

Backend overview

How to migrate simple existing applications to NX

Migrating backend app to NX

How to extract library with DTOs classes from backend app and prepare it to be shared with frontend application

Extracting shared DTO library

Let's look at how our final application should look like

Design overview

Add new Angular apps to the existing NX repository

Adding new Angular apps to existing monorepo

Adding Storybook to monorepo - different approach

Using previously configured Storybook in this lesson we will create and prepare a few common components that later we’ll use in apps.

Adding common components. Card, Button, Input, List, ListItem

Adding a domain library for RoomList, RoomBackground and RoomTimelineList that I missed in previous lessons

Constructing the services of the application

Constructing the application - Services

Constructing the Admin application

Constructing the Room application

How to prepare the application to work offline

Preparing the Room applications to work offline

Summary of building a real-life application with NX

Lessons learned and homework

Building a real life application with NX

Sixth module introduction

What is the dependency graph in NX, and how does it help you with developer experience

Dependency graph - what is it?

Why it’s important to keep the dependencies organized

Importance of keeping dependencies in order

How to run unit tests and lint only on the affected parts of the dependency graph

Affected

How to deal with the most common examples of circular dependencies

Dealing with circular dependencies

Sixth module summary

Dependency graph

Seventh module introduction

How to automatically migrate simple applications to the NX mono repository

Automatic migration of existing applications

How to manually migrate complex applications to the NX mono repository

Manual migration of existing applications

What may be the problem during migration of big, stale existing codebases

Analysis of potential problems in migration of big existing codebases

Tips. The migration plan

Why defining a target architecture may be an important step of the migration process

Tips. Target architecture

Seventh module summary

Migrating existing applications to NX

What you have learned from this course

Contact info and final words from the author

Final words

Summary

### Challenges and solutions in building large Angular apps

In large Angular applications, developers face several significant challenges. One major issue is managing complexity. These apps have lots of components, services, and modules that all need to work together smoothly. Keeping everything organized and easy to understand can be tough, especially with a big team.

Another problem is build times. As the app grows, it can take longer and longer for changes to show up during development. This can slow down the development process and make it harder to stay productive.

Dependency management is another headache. This involves making sure all the different parts of the app work well together and play nicely with outside libraries. 

### Tool limitations

Even experienced teams can struggle with managing large Angular applications without using the right tools. Organizing numerous components, services, and modules becomes challenging without tools that aid in clarity and team collaboration. Utilizing appropriate tools is key for experienced teams to successfully navigate the complexities of large Angular projects.

### Fixing problems with NX

NX offers several benefits for managing large Angular applications. It helps reduce the time it takes to build projects and keeps code well-organized by managing dependencies and structuring code into reusable parts. This makes it easier to maintain and expand applications over time.

One of NX's strengths is its ability to speed up builds. It does this by remembering previous build results and doing multiple tasks at the same time. This saves developers time and lets them make changes quickly.

NX also comes with tools for testing and checking code quality. It works well with common testing tools and helps keep code clean and consistent. This catches mistakes early and ensures code stays high-quality.

Furthermore, NX makes it easy to work together on projects. It keeps all code and shared parts in one place, making it simpler to share code between different projects or teams. This improves teamwork, reduces problems with combining code, and makes development smoother overall.

Manage Large Angular Apps and Supercharge Development Workflows

Learn how to create and maintain Angular applications using NX. 
Designed for Angular developers, this course covers best practices, improving workflow, and migrating existing applications to NX. 
Discover how to configure tools like Cypress for end-to-end testing and Storybook for UI component development. 
By the end of this course, you will have the knowledge and experience to work comfortably with NX on a daily basis.

Next-Level Angular Apps with NX

Build a simple time tracker application using NX monorepo.

Create a real-life NX monorepo with three applications. The main goal of these applications is to display the schedule for conference rooms on screens mounted to the doors of the respective rooms.

Build an admin panel as one of the applications to manage the schedule data for the conference rooms.

Use NX graph feature to visualize application architecture.

What is a monorepo approach and how it might help you

Differences between Angular CLI projects and NX projects

How to create Angular applications using NX

How to add Cypress and Storybook to your NX monorepo

How to migrate existing Angular applications to NX monorepo

What is a dependency graph and how to use it to save your time

How to prepare migration even for big and complicated projects

In previous lessons,
we focused on why the NX graph is such an important feature
and how many problems you may avoid by keeping your dependencies in order.

The NX graph is not only a cool visual representation of your application,
but it may be used to determine which parts of your application are affected by a commit.


In this lesson, we're going to look closer at the 

We need to introduce a slight change in one of the components.
I decided
to add a simple 

export class RoomTimelineListComponent {

  @Input({required: true})
  meetings: Array<Meeting> = [];

  constructor() {
    console.log('RoomTimelineListComponent');
  }

Please change a few files and observe what is happening on the graph.

To display the affected graph for the last commit, you can use the command presented below.

yarn nx affected:graph --base HEAD^ --head HEAD

This command compares changes between commits pointed in 

.
You can put their branch names, commit SHA, tags, or basically whatever works with Git.

The graph will show which libraries must be rebuilt because of changes in 

If you wonder,
if there is an option to check which libraries and applications will be affected before making a change,
you can use the 

yarn nx affected:graph --files libs/shared/components/list/src/lib/list/list-item.component.ts

To check what will be affected by uncommitted changes, you can use the 

For CI purposes, or when you want to create some utility script,
You probably prefer to get affected as a text of some kind.
You can do it with the 

---
title: Affected
description: How to run unit tests and lint only on the affected parts of the dependency graph
code: https://gitlab.com/fullstackio/books/newline-course-apps/building-angular-applications-with-nx-app/-/tree/main/manuscript/code/05.04-affected?ref_type=heads
privateVideoUrl: https://stream.mux.com/LGeyOUo01L01400ZchIg3y1ec1vtOcIsu02POU01CirQt8I00.m3u8
---

In previous lessons,
we focused on why the NX graph is such an important feature
and how many problems you may avoid by keeping your dependencies in order.
**The NX graph is not only a cool visual representation of your application,
but it may be used to determine which parts of your application are affected by a commit.**
In this lesson, we're going to look closer at the `nx affected` command.

## Changes

We need to introduce a slight change in one of the components.
I decided
to add a simple `console.log` to `room-timeline-list.component.ts`

```typescript { actualFilename=../../../manuscript/code/05.04-affected/libs/components/room-timeline-list/src/lib/room-timeline-list.component.ts endLine=40 startLine=32 statedFilename=libs/components/room-timeline-list/src/lib/room-timeline-list.component.ts url=https&#x3A;//gitlab.com/fullstackio/books/building-angular-applications-with-nx/module_06/lesson_06.04/.../../manuscript/code/05.04-affected/libs/components/room-timeline-list/src/lib/room-timeline-list.component.ts#L32 }
export class RoomTimelineListComponent {

  @Input({required: true})
  meetings: Array<Meeting> = [];

  constructor() {
    console.log('RoomTimelineListComponent');
  }
```

Please change a few files and observe what is happening on the graph.

## Affected graph

To display the affected graph for the last commit, you can use the command presented below.

```bash
yarn nx affected:graph --base HEAD^ --head HEAD
```

This command compares changes between commits pointed in `--base` and `--head`.
You can put their branch names, commit SHA, tags, or basically whatever works with Git.

![Affected graph](https://d2uusema5elisf.cloudfront.net/courses/next-level-angular-apps-with-nx/module_06/lesson_06.04/public/images/05-04-01.png)

The graph will show which libraries must be rebuilt because of changes in `room-timeline-list.component.ts`.

If you wonder,
if there is an option to check which libraries and applications will be affected before making a change,
you can use the `--file` flag.

```bash
yarn nx affected:graph --files libs/shared/components/list/src/lib/list/list-item.component.ts
```

![Affected graph with --files flag](https://d2uusema5elisf.cloudfront.net/courses/next-level-angular-apps-with-nx/module_06/lesson_06.04/public/images/05-04-02.png)

To check what will be affected by uncommitted changes, you can use the `--uncommitted` flag.

galczo5

The next graph is not only a cool visual representation of your application,

but it may be used to determine which parts of your application are affected by

So let's start by introducing a small change in the code.

In Leaps Shared Components, Room Timeline List, Source Leap, and Room Timeline

So let's introduce something simple. It doesn't need to be a very complicated

So let's add a constructor and a console log inside.

So we have console log with name of the component.

So we have a simple change. Let's switch to the console and I will show you

So I can use a simple comment to show what is affected by the change that I

We have simple comment, yarn and x affected graph and then two additional

So we are comparing two states of Git repository, so we have to provide base

So base is the starting point and hat is the newer version.

So I'm using one comment app, so I'm just checking the recent changes.

And as you can see, we can access localhost, 40 to 11/projects to check the

Alright, as you can see, everything is empty at the moment.

I'll always, it's our starting point, but we have one additional button on the

We have show affected projects. Let's click it.

And as you can see, our change in a room timeline list component affects admin

room front-end application, storybook and end-to-end tests to all three

So with that simple comment, you can check what's going to happen to your

You can not only use an X graph to show affected changes, you can try to

investigate what's going to happen if you introduce the change.

So I'm going to provide a comment, yarn and X, affected graph with additional

So I can provide a path to files and check what's going to be affected if I

We have that actionable button show affected projects, and you can see all

libraries and applications that will be affected by change in list component.

So we have our room timeline list, storybook, room front-end, admin front-end,

and end-to-end tests to both applications and storybook.

All these graphs are very nice, but not very useful in automation.

So when you automate some things, for example, you have a script that you want

probably want to have an output with list of all components or libraries or

applications that were affected by a change.

So let's type a comment, yarn and X, show projects with additional flag

And after executing this comment, you have a list of affected libraries and

And you can pass this list to your script, to your CI process, basically to

So this list is probably more useful for automation than the graph application

So you may wonder, if you have a list of affected applications and libraries,

do I really need to write special scripts to run, for example, tests or linter?

So for the standard operations, like unit tests, end-to-end tests, linter, you

So the comment is yarn and X affected with three additional flags. We have base

and head, like previously, we have one additional target.

So you can specify which target in Project JSON it should execute. In my case,

As I expected, unit tests are not working because we are not focusing on them.

I want to show you what will happen if I run the same comment, yarn and X

And as you can see, lint was executed on admin front-end, room front-end, admin

front-end end-to-end, room front-end end-to-end, storybook, and storybook end-

Affected command has some additional important options I want to mention.

First one is additional flag parallel. Because it's a graph, you can execute

With parallel, you can specify how many workers you want to use.

Please remember that using high number of workers might be CPU-heavy.

With additional flag exclude, you can exclude some projects, some libraries or

So for example, you want to run lint target on all affected applications, but

With flag untracked, you can show affected for untracked files.

There is additional verbose flag to print some more additional information.

With annex bail flag, you can stop processing on the first fail and save you

You can ignore cycles using annex ignore cycles flag.

In the last option, "Oh", you can run all targets, not only on affected

libraries and projects, you can run for all of them.

The main and obvious reason to use the affected command is to reduce building

If nothing changes in some libraries, why should we waste time doing

It helps you with the context switching because you can switch faster.

You don't need to wait for result of your unit tests or e-to-a tests.

What is more important, you can save time on continuous integration.

Continuous integration usually costs you money and less time spent on unit

tests, building and so on on CI means that you save money.