How using NX in Angular project improved our quality
Written by Sadmir Abdulahovic , Solution Architect at Softray Solutions
When starting an angular application the first decision we need to make is how to organize the code. An enterprise application contains multiple libs shared beetween apps and possibly developed by different teams.
Initially for our enterprise app we chose to start with an approach where each lib/app are stored on a seperated repository. Using this approach, for each new lib, we had to create a new repo, configure a new environment, copy over all configuration files, setup CI/CD pipeline and so on. If we had to change something in our build system, we had to go over each repo, do a commit, create a pull request, and wait for each build, which slows us down a lot. Soon we recognized this approach as hard to maintain and we decided to move to mono repo.
Instead of having a lot of repositories with their own configs, we decided to have only one source of truth — the monorepo. The monorepo approach fixes all of these pains and makes it very easy to share code across apps and libs. Since everything is located inside one repo, we can configure CI/CD and bundler once and then just re-use configs to build all packages. Same goes for unit, e2e, and integration tests — our CI will be able to launch all tests without having to deal with additional configuration. Instead of doing a pull request for each repo, figuring out in which order to build your changes, we just need to make an atomic pull request which will contain all commits related to the feature that you are working on.
Build optimization
Meanwhile, since we have created a mono repo using angular cli we started to struggle with other mono repo challenges. We had a lot of source code in one place and as the code base grew, the tooling was getting slower and it took way more time for CI to run everything.
We want to make sure that our build is efficient and that we only test and build the affected code. The thing about monorepos is that we need some tooling for the CI/CD pipeline to handle this in a scalable manner. That means, that if we change a shared lib we want to retest and rebuild the dependants. To do this we needed better tooling for CI/CD system to know which dependants to retest and rebuild.
All of those mono repo challenges we solve using Nx angular extension which gave us great tooling for working with monorepos including running unit tests, build and E2E tests for only the affected apps and libs.
Project dependencies
Without mono repo every time we had a new change in a shared repo we had to go to all clients and update their npm packages. There can be mismatches with different npm packages for the clients, eg. different Angular or Typescript versions, making it hard to share code.
In mono repo we have an easier dependency management. Only one package.json. No need to re-install dependencies in each repo whenever you want to update your dependencies.
Unit tests
Testing application with the toolkit provided by the Angular cli was slow, because there were many unit tests added. We wanted to test only affected changes and we achieved this using Nx. We removed Karma and switch to Jest as a test runner and it was an easy task using Nx. Jest is fast and allow us to validate changes quicker. It is built with usage in monorepos in mind and this is the main reason why it is a good alternative to Karma within a Nx Workspace.
From our expirience we manage that Nx is a great tool for implementing mono repo and it help us a lot to move from many repo and improve code maintenance and quality.
If you enjoyed reading this, click on the clap button so others can find this post.
