ae364864f6
It is quite common for the TS compiler to have to add synthetic
types to function signatures, where the developer has not
explicitly provided them. This results in `import(...)` expressions
appearing in typings files. For example in `@ngrx/data` there is a
class with a getter that has an implicit type:
```ts
export declare class EntityCollectionServiceBase<...> {
...
get store() {
return this.dispatcher.store;
}
...
}
```
In the d.ts file for this we get:
```ts
get store(): Store<import("@ngrx/data").EntityCache>;
```
Given that this file is within the `@ngrx/data` package already,
this caused ngcc to believe that there was a circular dependency,
causing it to fail to process the package - and in fact crash!
This commit resolves this problem by ignoring `import()` expressions
when scanning typings programs for dependencies. This ability was
only introduced very recently in a 10.0.0 RC release, and so it has
limited benefit given that up till now ngcc has been able to process
libraries effectively without it. Moreover, in the rare case that a
package does have such a dependency, it should get picked up
by the sync ngcc+CLI integration point.
PR Close #37503
Angular Compatibility Compiler (ngcc)
This compiler will convert node_modules compiled with ngc, into node_modules which
appear to have been compiled with ngtsc.
This conversion will allow such "legacy" packages to be used by the Ivy rendering engine.
Building
The project is built using Bazel:
yarn bazel build //packages/compiler-cli/ngcc
Unit Testing
The unit tests are built and run using Bazel:
yarn bazel test //packages/compiler-cli/ngcc/test
Integration Testing
There are tests that check the behavior of the overall executable:
yarn bazel test //packages/compiler-cli/ngcc/test:integration