{"componentChunkName":"component---src-templates-blog-post-js","path":"/multiple-packages-repository-with-angular/","result":{"data":{"site":{"siteMetadata":{"title":"Fabrizio Fortunato","author":"Fabrizio Fortunato","siteUrl":"https://izifortune.com"}},"markdownRemark":{"id":"7aa5be91-d6b0-5f45-959e-8eb737f9f2a8","excerpt":"Managing modules across different applications can be challenging for Angular applications. There are different approaches that you can take that will impact…","html":"

Managing modules across different applications can be challenging for Angular applications. There are different approaches that you can take that will impact your code and i’ve discussed some in my previous post the implications as well Managing Modules with Angular.

\n

Update 16/09/19: I’ve published a new article with an updated view on monorepositories\nhttps://izifortune.com/share-angular-libraries-with-lerna/.

\n

In here we are going to explore how to manage in monorepository different modules with the ability also to publish them as separate modules.

\n

I will leverage NRWL/Nx an open source toolkit for enterprise Angular applications and ng-packagr a library for compiling your modules following angular format.

\n

Why

\n

Nx really shines for managing monorepositories and the philosophy behind it is to keep all your code in a single place.

\n

One big problem that you can have with this setup is that different teams may work on different applications and have different releases and timelines. A team should always reduce the impact of their changes to another and if you are sharing libraries with Nx and doing breaking changes on them you will need to take care of refactoring other applications that you hardly have work on.

\n

That’s why we can use semantic versioning, even if a breaking change its released another app can still use the previous version. Giving time to the team to adapt those changes.

\n

Setup

\n

Start by installing the latest Nx cli, and the latest @angular/cli globally

\n
npm install -g @nrwl/schematics @angular/cli
\n

This will install the create-nx-workspace binary. The next step is to create a workspace:

\n
create-nx-workspace common
\n

The command will create all the necessary files and folders that we will need for our repository.

\n

If you want to read more about how workspaces works you can\nread their documentation at nx-workspaces.

\n

Now that we have our workspace we can already start adding libraries or applications to our workspace.

\n

Since we want to use versioning for our libraries that’s where ng-packagr comes into play.\nng-packagr its a small library that transpile your library using the Angular library format.

\n

Using what David Herges demonstrated on the following repository https://github.com/dherges/nx-packaged we want to combine Nx and ng-packagr together.

\n
npm i --save-dev ng-packagr
\n

Let’s generate two libraries in our repository:

\n
ng generate lib mylib --nomodule\nng generate lib mylib-two
\n

Nx extends the @angular/cli schematics making possible to create applications templates while still using the cli.

\n

The option --nomodule will generate a general library not wrapping it in an angular module.

\n

This will generate our libraries inside the libs folder, what we should have is two folders:

\n
libs/\n  mylib/\n  mylib-two/
\n

What we need to add is a package.json inside each library folder:

\n
{\n  "$schema": "../../node_modules/ng-packagr/package.schema.json",\n  "name": "@common/mylib",\n  "version": "0.0.0",\n  "ngPackage": {\n    "lib": {\n      "entryFile": "index.ts"\n    },\n    "dest": "@common/mylib"\n  }\n}
\n
{\n  "$schema": "../../node_modules/ng-packagr/package.schema.json",\n  "name": "@common/mylib-two",\n  "version": "0.0.0",\n  "ngPackage": {\n    "lib": {\n      "entryFile": "index.ts"\n    },\n    "dest": "@common/mylib-two"\n  }\n}
\n

This way ng-packagr can start packaging our libraries for us. In fact if we run\nng-packagr -p libs/mylib/package.json && ng-packagr -p libs/mylib-two/package.json after the command run you will notice both the libraries compiled under @common folder.

\n

Tools

\n

Now we need to take care of building our libraries. In a recent post in the NRWL/blog Victor Savkin introduced a new feature on Nx for smarter and faster buils using the toolkit.

\n

This enhance the Nx toolkit giving you the ability to build only the applications that actually have changed instead of rebuilding the whole repository.

\n

If you inspect your package.json at this point you will notice that there are a series of scripts

\n
"apps:affected": "node ./node_modules/@nrwl/schematics/src/command-line/affected.js apps",\n"build:affected": "node ./node_modules/@nrwl/schematics/src/command-line/affected.js build",\n"e2e:affected": "node ./node_modules/@nrwl/schematics/src/command-line/affected.js e2e",\n"affected:apps": "node ./node_modules/@nrwl/schematics/src/command-line/affected.js apps",\n"affected:build": "node ./node_modules/@nrwl/schematics/src/command-line/affected.js build",\n"affected:e2e": "node ./node_modules/@nrwl/schematics/src/command-line/affected.js e2e",
\n

We will leverage that but we need to customize it for libraries since those scripts are only available for applications in nx.

\n

Add these scripts inside the scripts folder.

\n\n

The file utils.js contains just a set of utilities that we will use into our different scripts.

\n

libs-affected.js instead just print out the libraries that are affected from our changes.

\n

Before testing it out we need to add fs-extra in our devDependencies.

\n
npm i --save-dev fs-extra
\n

And also let’s create a script inside our package.json to call libs-affected.js script.

\n
"libs:affected": "node ./scripts/libs-affected.js libs",
\n

Let’s start by committing our changes that we have so far.

\n
git commit -am 'Initial commmit'
\n

Now generate a new component for mylib-two:

\n
ng generate component myButton --app=mylib-two
\n

Once again let’s commit our changes:

\n
git commit -am 'Add myButton'
\n

If we run now npm run libs:affected -- HEAD HEAD~1\nthe output should be: mylib-two. The script its returning the library affected since the last commit. Notice that i’m passing the option HEAD HEAD~1 which compare the current commit with our previous. libs:affected supports the same arguments as apps:affected from Nx you can invoke the commands either passing the list of the changed files or two commit SHAs.

\n

To test it even further, let’s import mylib into mylib-two, commit our changes and then modify only mylib, the script should print out to console mylib mylib-two.

\n

Build

\n

Once the number of library will start to growth we definitely don’t want to add each library into our build script to be invoked. Using libs-affected we can automate this whole process and build only the changed/affected libraries.

\n

We will need another scripts to be added:

\n\n

And add this to our npm scripts:

\n
"build:libs:affected": "node ./scripts/libs-build.js build",
\n

Running npm run build:libs:affected -- HEAD HEAD~1 will trigger ng-packagr build only on those libraries.

\n

Test

\n

Another important step that we want to guarantee in our repository its testing. In one of my previous Unit testing angular applications with jest i’ve discussed how to start unit testing with jest. Let’s assume that we have already setup jest as our test framework what we need a command that will invoke only the tests of our changed libraries.

\n\n

And as always another npm script:

\n
"test:libs:affected": "node ./scripts/libs-test.js libs",
\n

This is especially good if you are covering unit tests. On the other hand if you have integrations tests than it will be better to run all your tests suit all the time.

\n

Bonus: versioning & release automation

\n

The last step that we want to automate in our repository will be related to versioning and releases.

\n

Leveraging lerna and standard commit we don’t need to manage ourselves all that.

\n
npm i --save-dev lerna\n./node_modules/.bin/lerna init
\n

This will install lerna in our repository and initialise it. In order for lerna to work we have to modify the file lerna.json that was just created:

\n
{\n  "lerna": "2.7.0",\n  "packages": [\n    "libs/*"\n  ],\n  "version": "0.0.0"\n}
\n

Add another extra script:

\n\n

And the last npm script:

\n
"prerelease": "lerna publish --skip-npm",\n"release": "node ./scripts/libs-publish.js",
\n

The prerelease script will take care of increasing the version of our libraries, commit our changes and tag also the commit. Notice that we are passing the flag --skip-npm because the actual publishing of our libraries will be done by our script.

\n

Using a tool like commitizen you can also add the flag --conventional-commits which will calculate automatically your next version based upon your commit message.

\n

If you are dying to start using it for your libraries here’s a link to a repository with all the steps already in place.

\n

https://github.com/izifortune/nrwl-packagr

\n

Enjoy!

","frontmatter":{"title":"Multiple packages repository with Angular","date":"January 18, 2018","description":null,"socialImage":{"childImageSharp":{"fixed":{"src":"/dist/static/1854f16a71123340b9ebc020ecf346e7/048fd/nrwl-nx-ng-packagr-1.png"}}},"image":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAJCAIAAAC9o5sfAAAACXBIWXMAAAsSAAALEgHS3X78AAABH0lEQVQoz2PQLT+OhrQrTijVX1Csv2hafMCw9LBiw2XV2vM6FScwVTJgChmWHI4Onz/dIPcki8N6HtdayzLvuJV6ZccIaNYvO6pSez7Xe8JzBo2XDJq3bTVP6qidYVA7xqDjkbhGveYsmhGYms/Fh815yqBzyUXj2lXPSwccD2tq7GcwccjcolF9Br/mY2q1Z33i1t4R1j9zWOHcac1bjyMuLzdZJ2BnkbdXu+okPs1AOY3q005ZW28zmN2wVb10zf3cfofT8gqrhD2BjtIBqTmGL8B0yk8YlB5ZoJn6nEH7roXaKU1VoIcrbKox3Yw1tI8BY0W9+kxi2OwdPH5zJCO8klaq15zDDGrsUQVxm2L9Jb3yo0B/qtRdwBpPQAQAzeP4qrtVBFsAAAAASUVORK5CYII=","aspectRatio":2.287671232876712,"src":"/dist/static/4ae32e8228d4b6f7529f1b0ef36d2294/a5924/nrwl-nx-ng-packagr-2.png","srcSet":"/dist/static/4ae32e8228d4b6f7529f1b0ef36d2294/17cc0/nrwl-nx-ng-packagr-2.png 167w,\n/dist/static/4ae32e8228d4b6f7529f1b0ef36d2294/f7869/nrwl-nx-ng-packagr-2.png 333w,\n/dist/static/4ae32e8228d4b6f7529f1b0ef36d2294/a5924/nrwl-nx-ng-packagr-2.png 666w,\n/dist/static/4ae32e8228d4b6f7529f1b0ef36d2294/bc46a/nrwl-nx-ng-packagr-2.png 673w","sizes":"(max-width: 666px) 100vw, 666px"}}}}}},"pageContext":{"slug":"/multiple-packages-repository-with-angular/","previous":{"fields":{"slug":"/managing-modules-with-angular/"},"frontmatter":{"title":"Managing modules with Angular"}},"next":{"fields":{"slug":"/performance-budgets-with-lighthouse-lighthouse-keeper/"},"frontmatter":{"title":"Performance budgets with Lighthouse - Lighthouse keeper"}}}}}