1

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

Dani P.
  • 1,073
  • 1
  • 10
  • 28

2 Answers2

2

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

  1. 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.

Jasmonate
  • 752
  • 1
  • 8
  • 18
  • Thanks for your comment Jasmonate. In our case, the idea of versioning may be useful to keep each module under control and avoid mistakes by unexperienced developers in the main project. Using libraries sounded like a option, similar to Maven un Java projects we have. – Dani P. Mar 16 '19 at 17:16
  • 1
    Git flow and code review can do that well enough. Have each developer fork the main project and submit pull requests that should be reviewed by a senior before merging. See here... you want to control development through versioning? Well guess what... *git has that already*, and it's simultaneously more flexible and controlled. Merge, cherry-pick, do what you like. Any additional versioning must be meaningful for the whole project, or else you'll be better off simply using git or subversion's forking and merging to contain mistakes. Again, this is all just my own opinion :) – Jasmonate Mar 16 '19 at 17:25
  • There will be no strict versioning between these modules, they will evolve independently. So we are looking for Independency rather than Consistency I think. P.S. Late edit for prev comment – Dani P. Mar 16 '19 at 17:26
  • 1
    If they're all independent, feel free to try. I think it's not a bad idea as long as you maintain a large degree of independency. I'm not saying they have to be business-independent *all the time*. If you feel that they would be independent most of the time, then you're probably justified for that approach. Just make sure you are fully informed of the risks in versioning - if you've thoroughly considered that, then go ahead! – Jasmonate Mar 16 '19 at 17:35
  • I think Im leaning towards using projects inside the app workspace, just for better code organization, and leaving aside the idea of versioning and library dependencies with npm, except for those parts that are truly reusable and decoupled of course. This other thread helped: https://stackoverflow.com/questions/50996354/angular-module-vs-library – Dani P. Mar 17 '19 at 12:19
1

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

Lalith Katta
  • 61
  • 5
  • Thanks Lalith, it is a very interesting approach but right now we are just beginning with Angular (migrating from Java Swing client to web app), so we wouldnt like to over-complicate the frontend architecture. – Dani P. Mar 16 '19 at 22:20