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.

Comprehensive guide to Angular and NX: Build, migrate, and decompose your Applications

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.

Building Angular applications 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 this lesson, you will learn about buildable and publishable libraries in NX. We'll check the difference in code and why it's worth using it in your projects.

Our lesson we'll start by creating a new NX mono repository, adding a new Angular application and a new default library. You should know how to do this right now, but I'm posting the commands for 

npx create-nx-workspace
yarn add -D @nx/angular
yarn nx g @nx/angular:app app-name --prefix app
yarn nx g @nx/angular:lib lib-name --prefix app

You should end with a message similar to this:

>  NX  Generating @nx/angular:library

CREATE libs/angular-lib/project.json
CREATE libs/angular-lib/README.md
CREATE libs/angular-lib/tsconfig.json
CREATE libs/angular-lib/tsconfig.lib.json
CREATE libs/angular-lib/src/index.ts
CREATE libs/angular-lib/src/lib/angular-lib.module.ts
CREATE libs/angular-lib/jest.config.ts
CREATE libs/angular-lib/src/test-setup.ts
CREATE libs/angular-lib/tsconfig.spec.json
CREATE libs/angular-lib/.eslintrc.json
UPDATE tsconfig.base.json

When you generate the default library for Angular and use it in your application, it will be integrated with your application code. It means that when you build your application, your library 

will be compiled as a part of the application.

This way has some disadvantages. Imagine that you have a few applications and hundreds of libraries. It means that the same code will be compiled multiple times whenever you want to build all your apps. It takes a lot of time, we should save.

The advantage is that this way of keeping libraries is straightforward.

 parameter in the generator command. So the command will look like:

yarn nx g @nx/angular:lib lib-name --prefix app --buildable

The output should look like in the example below. You can notice a difference easily.

>  NX  Generating @nx/angular:library

CREATE libs/angular-lib-buildable/project.json
CREATE libs/angular-lib-buildable/README.md
CREATE libs/angular-lib-buildable/ng-package.json
CREATE libs/angular-lib-buildable/package.json
CREATE libs/angular-lib-buildable/tsconfig.json
CREATE libs/angular-lib-buildable/tsconfig.lib.json
CREATE libs/angular-lib-buildable/tsconfig.lib.prod.json
CREATE libs/angular-lib-buildable/src/index.ts
CREATE libs/angular-lib-buildable/src/lib/angular-lib-buildable.module.ts
CREATE libs/angular-lib-buildable/jest.config.ts
CREATE libs/angular-lib-buildable/src/test-setup.ts
CREATE libs/angular-lib-buildable/tsconfig.spec.json
CREATE libs/angular-lib-buildable/.eslintrc.json
UPDATE package.json
UPDATE tsconfig.base.json

---
title: Built-in library types in NX
description: What are buildable and publishable libraries
code: https://gitlab.com/fullstackio/books/newline-course-apps/building-angular-applications-with-nx-app/-/tree/main/manuscript/code/03.03-lib-types?ref_type=heads
privateVideoUrl: https://stream.mux.com/ZcbV6RanmZUHKQ9CtBH025kqADBgGXgdnNKHRPvGYYkg.m3u8
---

In this lesson, you will learn about buildable and publishable libraries in NX. We'll check the difference in code and why it's worth using it in your projects.

## Default

Our lesson we'll start by creating a new NX mono repository, adding a new Angular application and a new default library. You should know how to do this right now, but I'm posting the commands for `yarn` below anyway.

```bash
npx create-nx-workspace
yarn add -D @nx/angular
yarn nx g @nx/angular:app app-name --prefix app
yarn nx g @nx/angular:lib lib-name --prefix app
```

You should end with a message similar to this:

```text
>  NX  Generating @nx/angular:library

CREATE libs/angular-lib/project.json
CREATE libs/angular-lib/README.md
CREATE libs/angular-lib/tsconfig.json
CREATE libs/angular-lib/tsconfig.lib.json
CREATE libs/angular-lib/src/index.ts
CREATE libs/angular-lib/src/lib/angular-lib.module.ts
CREATE libs/angular-lib/jest.config.ts
CREATE libs/angular-lib/src/test-setup.ts
CREATE libs/angular-lib/tsconfig.spec.json
CREATE libs/angular-lib/.eslintrc.json
UPDATE tsconfig.base.json
```

When you generate the default library for Angular and use it in your application, it will be integrated with your application code. It means that when you build your application, your library **will be compiled as a part of the application.** Not a standalone project.

This way has some disadvantages. Imagine that you have a few applications and hundreds of libraries. It means that the same code will be compiled multiple times whenever you want to build all your apps. It takes a lot of time, we should save.

The advantage is that this way of keeping libraries is straightforward.

## Buildable

We can fix the situation using `--buildable` parameter in the generator command. So the command will look like:

```bash
yarn nx g @nx/angular:lib lib-name --prefix app --buildable
```

The output should look like in the example below. You can notice a difference easily.

```text
>  NX  Generating @nx/angular:library

CREATE libs/angular-lib-buildable/project.json
CREATE libs/angular-lib-buildable/README.md
CREATE libs/angular-lib-buildable/ng-package.json
CREATE libs/angular-lib-buildable/package.json
CREATE libs/angular-lib-buildable/tsconfig.json
CREATE libs/angular-lib-buildable/tsconfig.lib.json
CREATE libs/angular-lib-buildable/tsconfig.lib.prod.json
CREATE libs/angular-lib-buildable/src/index.ts
CREATE libs/angular-lib-buildable/src/lib/angular-lib-buildable.module.ts
CREATE libs/angular-lib-buildable/jest.config.ts
CREATE libs/angular-lib-buildable/src/test-setup.ts
CREATE libs/angular-lib-buildable/tsconfig.spec.json
CREATE libs/angular-lib-buildable/.eslintrc.json
UPDATE package.json
UPDATE tsconfig.base.json
```

galczo5

Let's talk about NX libraries for Angular applications.

So we have three kinds of libraries and I want to discuss all of them in this

So I have a monorepo with the default Angular application generated and we will

So as previously in our lesson, we need to execute Yarn NX generate at NX/Ang

and we need to add the name of our library.

So let's call it Angularlib and of course we need to set the prefix so - -

This kind of library we call the default library.

As you can see, we have some files generated and you basically can add this

your application or applications and use it.

It's very simple, you don't need to care about anything.

What is important here is that it's not like npm library, you cannot publish it

This kind of library will always be compiled as part of application.

So when you have two applications and both of them use that library, it will be

You don't want to spend time compiling the same library over and over with

The second kind of library you can have in NX/Monorepo is Buildable library.

So to generate one, you need to execute command yarn NX generate.

It's the same as previously but you need to add additional flag - - buildable.

And of course I need to change the name of library so Angular buildable library

The first noticeable difference here is that you will have more files generated

You will have ng package JSON and package JSON.

Which means that you can build this library without building the whole

And it is a huge difference because you can build it once and then use it

And this kind of library - Buildable library is like a halfway step between the

So let's generate the publishable library.

We will change the library name to publishable.

And you have to add one more flag so you have to leave that buildable flag and

And then it is very important to add import path.

So let's set the import path to my org/name of the library.

So the main difference between publishable and buildable library is that

You have the default one and you need to compile it with your application.

You have buildable library and you may build it without the whole application

And you have library that is publishable.

It is both buildable and publishable so we can build it and then publish it.

When you have at least buildable libraries it allows you to use the incremental

It means that if some libraries haven't changed in your comment there is no

them because you have the previous artifacts and you can use cached packages

This method helps you save CPU time on your CI or local machine.

For small or medium applications build time is almost never a problem.

But when you have application that is huge the build time may take maybe a

And if you can have the result the ng-serve comment or build on CI in short a

So if you ask me which one library type I prefer I would say that I prefer

Even if there is no way that you are going to publish it.

Having that idea behind your head that someday you may want to show it to other

And it's way easier to not publish publishable library and just use it

mono repo than trying to publish the default library.