Metadata version mismatch for module - Found vs Expected

27 Jul 2018

Upgrading minor version of node modules for Angular are simple and straight forward. In rare cases you may encounter errors like 'Metadata version mismatch', which is not due to change in Angular but the change in the third party Angular NPM module provided by the Open Source Software (OSS) authors.

Recently, I tried to upgrade ng-block-ui module from version 1.0.0-beta6 to 1.0.6 using npm command

npm update

 This command will automatically do minor version upgrade, which is suppose to have no breaking changes at all and it is meant just for bug fixes. The upgrade was fairly simple and completed quickly. When I tried to build the Angular App with the upgraded module, it ended in `metadata version mismatch` error. At first I was looking into the Angular module version number as the error seemed to be related to version numbers.

The version numbers in error message referred found as 4 and expected as 3. This is due to the internal Angular version for ng4 is `3` and ng5 is `4`. The version variation happened because Angular team had decided to skip Angular 3 release, the internal version number remained at 3 where as the package was released as Angular 4. That internal version number is still followed and used for assertions and other code implementation, so the version number difference still remains tied up to Angular. 

After some investigation and validation of the error location (i.e.,) ng-block-ui model.d.ts mentioned by the Angular build system, helped me to understand the issue. I opened up ng-block-ui package folder within 'node_modules' folder, surprised to see the ng-block-ui module package had reference to Angular 5 version, but my base project was still on Angular 4 & beta was supposed to be on Angular 4. So, finally to make my app work, I had to downgrade the package back to beta that is compatible with Angular 4.

Usually, whenever there are major changes... the package authors will change the major version number part. So that the dependent developers will know or be aware of the breaking change and restrain from unknowingly updating/breaking the build. But in this instance, the major change was within a minor version update.

I hope this post helps you identify & solve similar issues quickly.