Tim Deschryver

ng update: the setup


With the Angular 6 release, already a couple weeks ago, the CLI package @angular/cli also received an update (also version 6). You will probably already have heard of it or even used it, but this update of the CLI introduced a new command ng update. In short this updates your application and its dependencies by taking a look if any of the dependencies in your package.json has a new version available. For more details about Angular 6 release you can take a look at the resources at the bottom of this post.

If you want to automatically let the CLI update your own library when a user runs ng update you’ll have to plug into the ng-update hook. As an example we’re going to use frontal— a selectbox/dropdown component based on downshift - which is currently on version 1.0.0 and after running ng update we want to have version 2.0.0 beta installed. There are also some popular packages where you can take a peek: RxJs, angular/material2 and recently the NgRx packages.

Enough of the what, let’s take a look at the how!


The first step is to setup the schematics by creating a migrations.json file, the name isn’t set in stone so you can name it everything you want (RxJS named theirs collection.json).

In the schematics value there is a property for each migration, the property name itself isn’t used (I think) but must be unique. The important part here are the version and the factory values. version is used to match the current installed version to run the update against, in the example the update is going to run when version 1.0.0 (or lower) is installed. factory is used to point to a factory function where all the magic happens, in the example it will call the default function inside ./2_0_0/index. It’s also possible to specify a function, with the following syntax "factory": "./update-6_0_0/index#rxjsV6MigrationSchematic".

Update function

This is the function which is called during ng update. In the implementation below, the dependency version will be updated in the package.json. Note that it’s also possible to do more than just upgrading the version number, for instance if we take a look at angular/material2 it also runs some linter rules.

Wouldn’t it be 🍌 🍌 🍌 if all libraries would automatically fix (breaking) changes during this step, or at least let you know which steps you have to make in order to have a successful update?


Last, an ng-update entry must be added to the package.json. This is necessary to let the angular CLI know where to look for the migrations.


It is possible to test the factory function by creating a UnitTestTree, having a dependency to the library with the old version number. Next the migration is is run with runSchematic, expecting that the version number has been changed to the correct version.

To test the ng update command locally before publishing to npm you can use verdaccio, a lightweight private npm proxy registry. There is a resource at the bottom, which addresses this point in detail*.*


As result we can see that a new version is available after running ng update. I’m using the next flag to also include next tags because version 2 hasn’t been released yet.

we run ng update frontal — next and see that a new version is available

After running the update command we can see the version number is changed in the package.json and we can start using the version in our project 🎉.

the version number is updated to the new version after ng update frontal — next has ran

More resources

Please consider supporting me if have you enjoyed this post and found it useful:

Buy Me A Coffee PayPal logo
Support the blog Share on Twitter Discuss on Twitter Edit on GitHub