Angular Module vs. Library

Question

So great, the Angular has released version 6 and the CLI provides an option to generate libraries - something that they call a "highly anticipated feature".

Now, coming from a business perspective, I am wondering:

• why you would actually need this,
• why inside of an existing project and not a separate which you can install as usual via npm...
• and if you want this inside your project, why not use a module for that.

So I get it, publish something on npmjs and hope the whole world and future connected things need exactly that. Library, great.

Inside a big system in a even bigger company, we could reuse a library but we already were able to reuse stuff with a module. I need to build the lib separately and recompile every time I change something..

What are the reasons to use a library instead of a module?

(Currently I'd say that a lib can be even bigger than a module, so I would just use it to organize my application better)

Solution 1

On this website I found a great explanation.

Modules

Reside inside of a project and let us bundle components which belong together. We can import this module where we need it instead of declaring all components at the root level. I.e. a AuthModule can take care of all auth related stuff. No need to let the app know what Components this module is using.

Libraries

In corporations there are many different applications and some/many might move to be based on angular in the future.

DevOps want ease of mind and keep things in one place, so the Angular CLI Team introduced workspaces - which can contain more than one project.

Then sharing things like an AuthModule becomes easy. We make a library of it and share it among the different projects. No need to have this code being copied into the core folder of each project anymore.

Here the original text:

One of the least talked about features of Angular 6 is Angular CLI Workspaces. Workspaces or Angular CLI Workspaces give angular developers the ability to have more than one project in one workspace. This brings all your projects under the same workspace. This is not limited to applications but also angular libraries.

This gives developers the freedom of breaking down large applications into smaller applications and modules. The modules such as authentication module can then be shared across the applications using those specific modules. This improves the workflow by reducing code repetition using shared libraries that are generated and managed by Angular CLI.

Great! Thanks for the answer, with this it makes sense.

Solution 2

To extend @hogan answer:

• They also provide an easy way to build NPM packages by generating a "dist" folder that encapsulates the library and NPM releases away from the current dev state or dev workspace.

• Uses AngularCLI to create a workspace with the same name as our intended Angular library.

• --Prefix option, the AngularCLI generator will automatically use prefixes for the right library or component environment.

• The AngularCLI realizes that it needs "ng-packagr". It adds it to our devDependencies in our workspace package.json

• Usage, now you can build, test, and more directly from angularCLI.

Comments

[Ingo Bürk]

The library is created inside the workspace, which can contain many projects (monorepo). The individual projects can still be published independently.

[Sayantan]

I am sorry, but I still do not understand the reason. If my main app is part of the workspace (at least the folder structure shows that) then developers working with an SCM tool (like Git) will most of the time will have code conflicts and merges to resolve which probably won't be necessary. For eg, 3 developers are working on lib1, lib2 and app1 where lib1 and lib2 are libraries inside app1. Now, when they commit their code, due to nature of the project setup, at least 2 of them will have code merges and probably conflicts to resolve, not at all desired.

[hogan]

@Sayantan that is a question for git and not angular, however 3 developers should not work on the same file often and merge conflicts usually happen for a reason. in that case its always better to communicate and agree on the interface that a lib or a component so that it provides the needed functionali.ty