Sample code organization for a complex Angular project

The official documentation of Angular describes well, and angular-cli automatically creates the structure of a relatively simple project. But as it develops, complexity inevitably grows and there arises a natural need to somehow manage this complexity. Including due to decomposition.

( Image taken from "12 Things to Help Large Organizations Do Angular Right" )

This publication is a practical understanding of the articles "12 Things to Help Large Organizations for Angular Right" (Victor Savkin, Co-founder of Narwhal Technologies ( nrwl.io ) and "Angular: Understanding Modules and Services" (Michele Stieven, Web Developer & JS enthusiast ) through the prism of their own experience with the framework.

Task

Organize the source code of the application family with shared libraries so that it meets the following requirements:

• Mono repository - all source code in one repository with a single node_modules pack for all web applications and libraries.
• Compatible with angular-cli without additional add-ons and extensions
• Ability to independently compile libraries and build web applications.

Sample application

For example, let's create a working prototype of the hero-app application with the dependent library common-lib . For the example of two components it is enough, but in practice their number can be any reasonably.

Code organization

Apparently, the basic concept of angular-cli is to create exactly the workspace for the project family, and not the working directory for a single one. In any case, the property of apps as an array in .angular-cli.json hints at this unobtrusively. This opportunity and take advantage.

Create a working directory using the standard ng new , and then slightly modify it by placing the application and library in a separate folder in src - in fact, it will be the root folder for all the other "building blocks" of our solution.

Then we modify .angular-cli.json so that it adequately perceives our changes in the project structure:

(Note: Initially, it seemed that everything was simple, but there were (and there are) small surprises with relative paths and how angular-cli processes them)

I wanted to keep the library code as clean as possible, but since angular-cli requires specific values ​​in .angular-cli.json for normal operation, everything that is partly unnecessary, and somewhere and just common for all files, will be placed in the folder src / _common .

Import Libraries

Using the common root src folder for the entire code makes it technically easy to import the necessary files, but the code is:

import {FooBarComponent} from '../../../../../foo-bar.component'; 

Not only aesthetically looks awful, but also creates problems if we decide later to publish our libraries as independent npm packages.
Fortunately, the ability to configure tsconfig.json elegantly solves this problem.

Result

Now you can work independently with each component component of the overall architecture by decomposing the solution, and the common code base allows you to build the necessary modules and applications “out of the bricks”.

Important emphasis: not the way to create "real" libraries for Angular (this is another story like this one ) is described, but only a way to organize the code for a fairly complex project (there are other more professional tools to solve this problem).

Afterword

In order not to be distracted from the main topic of the article, there are still some interesting points behind the brackets, like:

• Connection of third-party libraries and styles and the removal of connection settings in the common code
• Using global styles to style nested components
• Connecting tslib (TypeScript helpers) to slightly reduce the size of the bundle
• Application organization techniques: AppRootModule, "features" -module, folder structure
  modules (using index.ts with re-export)
• Features of importing modules between root and child lazy-loaded modules (using Module.forRoot)

But, in one form or another, you can find examples of their solutions in the project code on GitHub or in the articles referenced in the text flow.