Better Angular App Architecture With Modules

2.5 Creating a Third-Party Module

Hi folks. In this lesson, we're going to see how we can create a completely stand-alone library that could be installed into other Angular projects, as if it were a module within that project. It's quite common to work on multiple projects in your professional life and very often there will be particular bits of code that you will use over and over again. In this case it makes sense to extract this code and package up into a reusable module that can be easily shared between projects. At the moment, we've got just a single project called Angular-Modules and one of the things it contains is a utils folder. This utils folder contains a single service which is a date service. And all this service does is return a formatted date string from moment JS. It's the kind of thing that we're going to want to do in many projects. So let's turn it into a reusable module that we can install into other projects, just like any other third party module that we might download from MBM. The Angular CLA now supports multiple projects. And one of the types of projects that we can generate is a library. So that's what we're going to do. Weve seen the generate command before but this time we use the prefix flag to specify the prefix for any generated selectors. If we don't do this the default is lib which is pretty generic Note that I've called the library dsw-utils. Utils itself is pretty generic. And in fact there's already several utils packages up on npm. So I've used my initials just before the library name just in case I ever want to publish this library to npm. So this command will do a bunch of things Let's go back to the code editor. And let's just refresh. So we can see that it's added a new projects folder. And inside this, it's added a root folder called DSW-UTools, which is the name that we gave to our library. Inside this is an src folder and some configuration files, including a package dot json file. Inside the rsc directory is a folder called lib, a file to expose the public api, the library and a file that loads the uni tests. The lib folder is for the internal files of the library Currently this contains a module and an example component and an example service. Another thing the generate command did is update the main angular.json file for the original angular modules projects with information about this new library. So we can see that the main Angular Module's Project is defined at the top here, as well as the End to End Project for Angular Module's Project. And we now have this dsw-utils section and that contains things like the paths to the configuration files for the library. And it also contains various commands that we can run including the "Test" command and the "Lint" command, so what this new configuration means is that we can run tasks for the library without having to move our command line into the new DSW U2's directory. So for example, if we wanted to run the unit tests for the library, we're not going to use the cd command at all. We can just do ng test, and we just need to tell it which project we want to run the tests for. And we do that using the project flag, and we specify the name of the project. If we don;'t specify which projects we'd like to run the tests for, it will run the tests for the main default projects which is we know is angular-modules. And you can see that the tests for the new libraries are running as expected. So our library isn't going to need the example component or the service that the CLI created for us. So first of all, let's go ahead and delete these files now. So we also need to update the module for the library. And we just need to get rid of this component and we can also remove references to the example component and service from the public API of the library. Okay, so now let's move the date service from the Utils folder into the library. We can get rid of this Utils folder altogether So now we can expose the date service from the library using the public API. Our library actually depends on MomentJS, which is included in the package.json of the main angular modules package. Really we should also specify as a dependency of the library. So I mentioned earlier that the library has it's own package.json file, let's open this up. And we can see that it already has a section for pair dependencies. And this is really the recommended way to specify dependencies for this kind of small library. So let's copy moments from the main package.json into the libraries package.json. We're not going to remove it from the main paackage.json because it's going to be specified as a dependency. So we should now be able to build our small library We do that using the NG build command and just specify the name of the project you want to build which in this case is dsw-utils. So this will create a distributable version of the library. And we should use this in our main project immediately, as if we had installed it just like any other package via NBM. We just need to make a few changes now in the main app.module file and the angular-modules\projects, because this will still be trying to import the date service As if it was still part of the project, so let's just fix that up quick. There are also references to the date service in some of our components, so we'll just need to update these as well. We still want to import the date service, but this time we're going to import it from our library. So let's go back to the command right now and check that everything is still building as it should. And you probably need to stop and restart the depth over once again. And everything is looking good, so lets just go back to the browser and just check the dates have been formatted in the correct way. And it certainly looks that that is the case. Let's just try doing a hard refresh, make sure nothing's cached. And everything is working in the way that it should do. Perfect. So we're importing date service from the And that is the same format that we would import it from if we have installed the library directly from npm And the reason why this works is because when they see that I generated the library, it also updated then TS convict file of the main project to add parts for the built version of the library. So we can see now in path section there is this DSW-utiles and that points to the dist folder Add a subfolder called dsw hyphen utils. That's also why we had to build the library before we could actually use it. And because the library has it's own package the jason file, we could very easily publish this to NPM from it's current directory and then not only would we be free to use it in as many projects as we wanted, but other people would as well. So in this lesson, we saw how we can very easily create a completely independent library aimed at being installed into other Angular applications. We learned that we can generate the library using the Angular CLI. And we saw how we can expose the functionality of services that are included In the library, using a public API file that gives us full control of exactly what we want to make available. This is a great way to refractor a commonality out of a project that we want tp share Between multiple projects, like almost everything else, the Angular CLI makes this super easy and completely painless. The example library only contains a single service, and this service only has a single method. And now that you know how to do it, there's no reason why you can't create your own libraries containing all of the tools and components, directives or pipes and services That you find yourself using over and over again. Thanks for watching.