Feature modules as libraries in Angular?

Question

We are working in a big application in Angular with many feature modules, each of them with many components, services and routes.

We are wondering if it would be a good idea to encapsulate these feature modules in libraries, so that we can import them as npm dependencies in the main project and have them under control.

The idea is that new developers can work only in the feature modules, using versions to keep things right and avoid problems in the main project. This would be similar to working with Maven in Java projects.

Key Note: These feature modules are not meant to be reusable in other apps, they are coupled to this app. The libraries would be useful for versioning and organization only in this case.

We have read quite a lot about Angular modules, but we would like some words of experience and real advice on this. We really appreciate any feedback.

Thanks in avance!

Dani

Answer 1

It might not be a good idea. Semantic versioning is, well, semantic , and using libraries as a development pattern might pollute your library releases and cause additional versioning and specification problems in the future.

There is, in my opinion, one point to consider:

1. Does each library have its own individual logic, with no interaction between other libraries?
2. OR does one logic affect all libraries, and can you preserve a meaningful and consistent versioning between these libraries?

If not, you will likely mess up versioning.

If libraries are not independent: for example if a business logic affects both lib-a@1.1.0 and lib-b@1.3.0, it will be incredibly tedious to document the CHANGELOG. If a bug is present and discovered only after a couple of versions, or a force revert is required, it will be extremely error-prone to revert and/or cherry-pick each library to the exact required version.

This is why libraries that are dependent on another ( @typescript-eslint/parser and @typescript-eslint/eslint-plugin , rxjs and rxjs-compat ) strictly requires you to use the exact same version number for each library - for example, you will have to install rxjs@6.3.3 and rxjs-compat@6.3.3 in the same project. You cannot safely use rxjs@6.2.3 and rxjs-compat@6.3.3 together. You are also recommended to install the same version numbers of core Angular framework libraries.

However, consistent versioning will likely can only be applied if each library is (most of the time) affected by the same business logic change. It will be meaningless to force consistent versioning even though no relevant changes have taken place.

My opinion

1. If you are able to preserve a meaningful and consistent versioning system and install the same version number consistently for each library

OR

2. If each library will have its own strictly individual logic with no interaction with other libraries

Then sure, try it.

Consistency , or independency . Take your pick.

Otherwise, just use git flow or trunk-based development, with strict code review and pre/post-commit lint checking and testing. Just my opinion.

Answer 2

If it is feasible for you, try to divide your each feature module as an independent microservice. For further reading about microservices, please take a moment and read this article: https://medium.com/@tomsoderlund/micro-frontends-a-microservice-approach-to-front-end-web-development-f325ebdadc16