4

I am writing a potentially large web application using Angular 7, where I came across a design problem. My angular applications until now have been relatively small, so there was no problem keeping whole code in one project (divided in modules with lazy loading). However now that an application can grow in size I find it hard to keep all code in the same project as it makes project hard to navigate.

My thoughts were that I could divide my application into multiple angular libraries by functionalities, which poses the following questions: do I really gain some advantage with such approach or do I just create overhead with managing dependencies making development harder because of having to link in all dependencies? If this option is viable, what would be good way to split code into multiple libraries? I have looked around for some articles about large angular apps but haven't found any with my solution - all were just one project - are there any good articles on such matter?

Miha Jamsek
  • 249
  • 2
  • 7

1 Answers1

2

The simplest way to do this (if you haven't done this already) is to split your Angular code into modules.

That introduces the posibility to clean each module up so that it is not dependent on other modules, or only dependent if it is supposed to be on top of another module. So it is definitely a good idea to do so, even in projects that have as little as 20+ components and services.

If you are using git you can take advantage of the submodule functionality in git to allow you to share your modules between projects. (But beware that submodules in git can give you some annoyances, I have had some issues with them and TortoiseGit, not lost any commits, but still.)

If you already are using modules and that is not sufficient for splitting up your project the next step will be to make packages to install in your project with npm (or manually doing the same by editing the projects .json files and copying to node_modules).

I don't think Angular has anything between these two ways of splitting up your code. It seems to be a design decision that 'libraries' have to be packages. And that seems to be a fair choice considering the general architecture of Angular.

Bent
  • 2,566
  • 1
  • 14
  • 18
  • Yes, I am already using modules (mostly due to lazy loading). I see, so there is not much I can do. Considering Angular has project namespace I thought it also supports to split code across namespace, without having the need to package them with npm first. I don't know whether I get enough advantage using npm packaged libs, since they are a bit tedious to link together. I'll probably stick to just one (very) big project. – Miha Jamsek Jan 07 '19 at 11:39
  • @MihaJamsek so you went with using a single codebase (repository) and just having different feature modules? I am also looking for a more lightweight way of combining Angular codebases and for now only using angular libraries come close - but with the disadvantage of having to publish npm packages first. – Anton May 03 '20 at 13:59
  • Yes, I try to split app into modules based on functionality. With exception of some generic components, which I put into separate library - altough I use private Nexus repository for faster (and less constrained) distribution – Miha Jamsek May 03 '20 at 14:07