Problems with enabling Ivy in Angular 10

Hello everybody

We have a problem with our angular app.

We recently updated to angular 10 and enabled Ivy and aot.

Now we are running into several problems that we are not able to solve.

Here is a quick overview of our setup

The app is enterprise sized and contains several libraries which depend on each other.

These libraries are then used in other angular applications/workspaces which themselves contain libraries that are used further.

Here is a simple illustrations of our setup:

Core repository:

CoreApp
--projects
---coreLibA
---coreLibB
--src
---components <-- uses code from coreLibs

User Repository

UserApp
--projects
---userLibA <-- uses core libs
---userLibB <-- uses core libs
--src
---components <-- uses core libs as well as code from userLibs

The core-libraries are build into a folder and are consumed by the user-application from that folder through NPM.

This works well with angular 10 without ivy.

First Problem

So, at first we enabled Ivy everywhere (libraries and applications). We were able to build the coreLibs without problems and install them into the userApp as well. ng serve on the userApp works as well. But when we tried to build the userLibs we encounter following error:

ERROR: Cannot resolve type entity i4.CommonModule to symbol
An unhandled exception occurred: Cannot resolve type entity i4.CommonModule to symbol

We were able to solve some of these errors by removing imported modules in ngModules that were not necessary. But sadly, we couldn’t solve all the issues.

We still don’t understand why this error occurs only with ivy and what it actually means.

Second Problem

We then tried to build the libraries without ivy but still run the application with ivy.

This way we were able to build the userLibs without problems. But when we tried to ng serve following error occurs:

ERROR in the target entry-point "coreLibB" has missing dependecies:
 - @angular/localize/init
 - @angular/cdk/platform
 - rxjs/operators
 - coreLibA
 ... and some more

We tried to work around that by adding hard dependencies in the libraries package.json and whitelist them in the ng-package.json. That worked, but npm install ran out of memory. So this is not a solution either.

Conclusion

It seems that Ivy is much stricter that View Engine. But we need Ivy to use the new localization feature of angular 10.

So we would really appreciate help with this problem. We know that we probably didn’t provide enough information, but we just don’t know what information is needed. So just let us know and we deliver.

Thanks for your help

[JoostK]

@honzikec thanks, that is super helpful. The situation is indeed as I expected, where the location of coreLib inside of local_modules means that it does not see @angular/common itself, as there is no node_modules directory in its ancestry tree. What was unexpected to me however that this worked in ViewEngine.

Upon tracing both compilers (Ivy and ViewEngine) to figure out where the difference occurs, I found this in the ViewEngine compiler:

https://github.com/angular/angular/blob/d1ea1f4c7f3358b730b0d94e65b00bc28cae279c/packages/compiler-cli/src/transformers/compiler_host.ts#L635-L637

The Ivy compiler does not do this, and this introduces a difference w.r.t. the symlink that is present for coreLib inside of userApp/node_modules. In VE, the symlink would be preserved such that all paths stay inside of userApp/node_modules, allowing these files to resolve files from within userApp/node_modules. In Ivy however, the symlink is resolved to its true location on disk, and this means that the userApp/node_modules tree is no longer “visible”, so to speak.

I don’t know why VE hardcoded the symlinking behavior, that probably goes back to a distant past where there was no ability to configure it otherwise. Today however there is such an option available as TS compiler option, which is preserveSymlinks. Your app can be built again when adding "preserveSymlinks": true to userApp/projects/user-lib/tsconfig.lib.json. In you situation, this sounds like the correct thing to do actually, as you’re actively depending on the standalone local_modules directory being adopted into the build.

As a final remark, please be aware that the library as compiled in coreApp must have the exact same version as userApp, as the coreApp is compiled with Ivy AOT instructions for the Angular version that is installed in coreApp, but then consumed in userApp. If the versions mismatch, the AOT output may be incompatible (full AOT output is not considered stable, we’re working on an intermediate representation to mitigate this).

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}