Migrations are failing, when @angular-devkit/core is not on root level in the node_modules

[Lipata]

Description

It is possible that the @angular-devkit/core is not at the root level in the node_modules. Migrations are developed so that they require that package on the root level, however, we should revisit that.

• igniteui-angular version: 17.0.x
• browser: N/A

Steps to reproduce

1. Have a project with @angular/core & @angular/cli version 16.2
2. ng update @angular-eslint/schematics @angular/cli @angular/core @infragistics/igniteui-angular
   or ng update @angular-eslint/schematics @angular/cli @angular/core @infragistics/igniteui-angular @igniteui-cli

Result

Migrations for igniteui-angular or igniteui-cli fails

Expected result

Migrations are executed

[Lipata]

We will do the following:

• dig deeper to understand the reason behind the missing @angular-devkit/core package on the root level.
• in any case we should:
  • see if we can get rid of the @angular-devkit/core dependency in the migrations
  • or see if we can load @angular-devkit/core dynamically, like we are doing with the language service

[kdinev]

@Lipata We can't rely on a package we depend on to just be present. We have to make sure we load the package regardless of whether the project already has it or not.

[jackofdiamond5]

@kdinev It seems to me like during an ng update to 17 the package @nguniversal/builders gets replaced with the package @angular-devkit/build-angular so it is removed from the package.json file.

Screenshot during ng update:

However, it is still present in the lock file which causes a peer dependency conflict, so the update schematic enforces an npm install which messes up the dependency tree and the resulting lock file does not have an @angular-devkit/core package at the root level, instead, it is only present for packages that explicitly list it as a dependency. This in turn causes the error in our migrations since we do not list it as a dependency even though we rely on it which, as you said, shouldn't be the case.

I managed to reproduce this behavior on a clean Angular project (without using ng update) using only dependencies and dev-dependencies from the bellum-gens repo. One solution for this problem is for the project to do a clean install or to remove the lock file before updating.

As for igniteui-angular we may be able to work around this by getting rid of all the code that we use from the @angular-devkit/core package or by listing the package as a dependency, or by installing it runtime during an update. These are far from ideal though as a much better solution (as proposed by @damyanpetev) could be to separate the migrations logic to a different package which has the core package listed as a dependency and install that during an update. This way we will not put additional load on igniteui-angular with an additional package and will be safe in case of any other shenanigans happening during an ng update.

[kdinev]

@jackofdiamond5 Deleting the package-lock worked, I confirm. Should I close the issue, if this is the solution?