Reading time: 3 minutes
In this post I will demonstrate how to test and debug Angular library. One of the scenarios where this might be helpful is when you developed a library and you want to test how it would behave before publishing it to a remote package registry like npm or other alternatives.
Another scenario is if you have a library that is already used by one of the applications and you need to debug some code that is dependent on library code.
What is required
- Visual Studio code or any editor of your choice
- Angular setup (to install Angular you need Node.js and npm package manager)
- Angular cli
Let’s create an Angular app
Open VS code and navigate to the root folder of the destination where you want to keep the code for this application.
In VS code new terminal type ‘cd destination-of-your-repo’ for example ‘cd C:\Users\dmitr\source\frontend\countries-ui’
Then type command ‘ng new name-of-your-repo’. In case you created the folder beforehand then you can run a command
ng new name-of-your-repo --directory=./ --skip-install
This would put application files into your folder without creating a nested folder structure.
Type ‘code .’ and it should open another VS code window with application code.
Next identify the folder where you package.json lives. You can run the command ‘dir’ to check if you are in the correct folder.
When you found it then run ‘npm install’
Let’s create a library app
We will place our library app inside the app that we created in the above steps. This is how Angular works in a sense you need to create a workspace that is like a parent app for other projects in out case an angular library.
Input this command in the terminal at the same location as the above app
ng generate library dg-library
Angular CLI should generate for us all the necessary files for the library.
Let’s create a consumer app
Using the same approach and following the same steps let’s generate a basic app that would be using our library app.
Once you are done we need to add the selector of our app into the html file of the consumer app.
Next in the workspace location you need to run a build command for the library. Worskpace is like a container for all the projects including the library. This is the way Angular organizes files.
Use command to build the library. This generates the build files in dist folder. *also make sure you run the npm install command first
ng build dg-library --prod
This creates dist folder with build files.
Let’s link these apps
After we have built the library app with prod flag we are ready to link these two apps.
For this we need to go to location of the library dist folder. For me this would be:
Then run this command
and you would get an output of
What happens is we have placed the library project files into a global node_modules location. You can run this command to find out the location.
npm root -g
The output location for me is
To complete the link of these apps we need to perform a similar steps in the consumer app.
In the consumer app use this command to complete the link.
npm link dg-library
Which is the same as the one we used for the library project but this time we specify the name i.e. dg-library.
This would add library files under node_modules folder of the consumer app.
To test simply run the consumer app.
ng serve -o
This should be the output in the browser.
Before we finish off let’s tidy up
In the consumer app run this command.
npm unlink dg-library
This would remove the link to from consumer to library app. Also remove library files from the node_modules in the consumer app.
And in workspace where you have library app you need to perform similar steps.
Go into dist folder of the library app.
This should remove the build files of the library app from global node_modules. You can check by running this command and getting the location of global node_modules folder.
npm root -g
Hope these steps were clear for you.
In summary we have created one basic app, one library and linked these locally.
This is handy if you have several projects and one of them consumes a remote library. If you have repository of that library you can manually hook in these and debug files on your local machine.
This could also be part of your routine before publishing your library to package manager of your choice.