When your app grows and you make components that could be reused in other apps it's a good thing to split out that code in a library. Also if your app is big already and someone else is going to add a new feature to it, it's much easier if they can work on that feature in a small isolated project and when ready import it into the main app as a library.
The architecture of Angular with modules help us organize the application code into blocks of functionality. The step of splitting into libraries should build on that, but add the benefits of not having to see code not relevant to the modules we're currently working on and to easily install and reuse in several applications without having to duplicate code across projects.
Creating an Angular library is basically about packaging compiled NgModules into a format that can be installed into another application using a package manager like npm. It could be done as easily adding the typescript sources and html templates to a tar.gz with a package.json entry point. However we'd like to save typescript compilation time in the main app by having a pre-compiled library, and also we'd like to make the package as small as possible by flattening and minifying. Also if we're going to use with module loaders like SystemJS we don't want trouble with component relative paths for the templates ( which in some cases requires a moduleId parameter in the component annotation), so to avoid this we'd inline the HTML/CSS templates instead of having them as separate files. So then there's actually quite a bit of work to be done for bundling a library.
But it's possible to automate this, and it doesn't have to be complicated.
The simplest approach would be a command line tool that takes the typescript entry-module source file path and library name as parameter, and emitted a tar.gz that could be installed to another project with npm.
So we did this.
It's sufficient for library re-use across Angular CLI projects, and also into SystemJS setups. It also bundles well with AOT both in the Angular CLI and rollup.
A simple video demo is here: https://youtu.be/6yu-YCqESZ8
And the tool can be found here: https://github.com/fintechneo/ngmakelib
The architecture of Angular with modules help us organize the application code into blocks of functionality. The step of splitting into libraries should build on that, but add the benefits of not having to see code not relevant to the modules we're currently working on and to easily install and reuse in several applications without having to duplicate code across projects.
Creating an Angular library is basically about packaging compiled NgModules into a format that can be installed into another application using a package manager like npm. It could be done as easily adding the typescript sources and html templates to a tar.gz with a package.json entry point. However we'd like to save typescript compilation time in the main app by having a pre-compiled library, and also we'd like to make the package as small as possible by flattening and minifying. Also if we're going to use with module loaders like SystemJS we don't want trouble with component relative paths for the templates ( which in some cases requires a moduleId parameter in the component annotation), so to avoid this we'd inline the HTML/CSS templates instead of having them as separate files. So then there's actually quite a bit of work to be done for bundling a library.
But it's possible to automate this, and it doesn't have to be complicated.
The simplest approach would be a command line tool that takes the typescript entry-module source file path and library name as parameter, and emitted a tar.gz that could be installed to another project with npm.
So we did this.
It's sufficient for library re-use across Angular CLI projects, and also into SystemJS setups. It also bundles well with AOT both in the Angular CLI and rollup.
A simple video demo is here: https://youtu.be/6yu-YCqESZ8
And the tool can be found here: https://github.com/fintechneo/ngmakelib
Comments