Affected

[00:00 - 00:14] 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 a comment. So let's start by introducing a small change in the code.

[00:15 - 00:27] So I'm in Room Timeline List component. In Leaps Shared Components, Room Timeline List, Source Leap, and Room Timeline List Component.ts file.

[00:28 - 00:36] So let's introduce something simple. It doesn't need to be a very complicated change. So let's add a constructor and a console log inside.

[00:37 - 00:48] 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 what we can do with affected graph.

[00:49 - 01:02] So I can use a simple comment to show what is affected by the change that I just added to my code. We have simple comment, yarn and x affected graph and then two additional parameters.

[01:03 - 01:13] So we are comparing two states of Git repository, so we have to provide base and hat. So base is the starting point and hat is the newer version.

[01:14 - 01:22] So I'm using one comment app, so I'm just checking the recent changes. Let's execute that.

[01:23 - 01:31] And as you can see, we can access localhost, 40 to 11/projects to check the graph. Let me switch to the browser.

[01:32 - 01:42] 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 left side in toolbar.

[01:43 - 01:59] We have show affected projects. Let's click it. And as you can see, our change in a room timeline list component affects admin front-end application, room front-end application, storybook and end-to-end tests to all three applications.

[02:00 - 02:17] So with that simple comment, you can check what's going to happen to your repository after the change. 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.

[02:18 - 02:35] So I'm going to provide a comment, yarn and X, affected graph with additional flag files. So I can provide a path to files and check what's going to be affected if I introduce the change in that file.

[02:36 - 02:54] 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.

[02:55 - 03:16] 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 to execute only for affected libraries, probably want to have an output with list of all components or libraries or applications that were affected by a change.

[03:17 - 03:31] And with an X, it's quite simple to do. So let's type a comment, yarn and X, show projects with additional flag affected, and two additional flags, like previously, base and head.

[03:32 - 03:46] And after executing this comment, you have a list of affected libraries and applications. And you can pass this list to your script, to your CI process, basically to whatever you want.

[03:47 - 04:05] So this list is probably more useful for automation than the graph application that I just showed you. 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?

[04:06 - 04:15] And you don't need to. So for the standard operations, like unit tests, end-to-end tests, linter, you can just execute a special comment.

[04:16 - 04:35] 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, it's unit tests.

[04:36 - 04:53] 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 affected with target lint.

[04:54 - 05:09] 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- to-end. Affected command has some additional important options I want to mention.

[05:10 - 05:23] First one is additional flag parallel. Because it's a graph, you can execute some tasks at the same time. With parallel, you can specify how many workers you want to use.

[05:24 - 05:37] Please remember that using high number of workers might be CPU-heavy. With additional flag exclude, you can exclude some projects, some libraries or applications from executing.

[05:38 - 05:49] So for example, you want to run lint target on all affected applications, but you want to exclude end-to-end tests. With flag untracked, you can show affected for untracked files.

[05:50 - 06:01] 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 time on CI.

[06:02 - 06:14] 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.

[06:15 - 06:25] The main and obvious reason to use the affected command is to reduce building time. If nothing changes in some libraries, why should we waste time doing unnecessary work?

[06:26 - 06:33] 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.

[06:34 - 06:48] 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.

[06:49 - 07:00] And what's important, if you are not able to run unit tests in reasonable time, you will avoid adding more unit tests. So your code might be not tested properly.

[07:01 - 07:17] When you run only affected tests, you can add as many unit tests as you want and you don't need to care about this limitation. And the last use case worth mentioning is using affected and show project comments to build your own tools and scripts.

[07:18 - 07:32] Every experience developer knows that every company has its own needs and we very often create internal tools to improve processes. Having a ready to use tool that solves the problem of tracking dependencies is a huge help.

[07:33 - 07:49] I guess after this lesson you have a lot of ideas how to use graph, how to use affected, how to improve your developer experience, how to save some time on CPU, on CI. And as you can see, graph affected and show projects are quite helpful.

[07:50 - 08:05] You can use them out of the box and that's a huge difference between an X mon orepo and the default angular CLI application. In the next lesson we'll focus on circular dependencies. We'll check how to create them and of course how to fix them.