f690a4e0af
Our module resolution prefers `.js` files over `.d.ts` files because occasionally libraries publish their typings in the same directory structure as the compiled JS files, i.e. adjacent to each other. The standard TS module resolution would pick up the typings file and add that to the `ts.Program` and so they would be ignored by our analyzers. But we need those JS files, if they are part of the current package. But this meant that we also bring in JS files from external imports from outside the package, which is not desired. This was happening for the `@fire/storage` enty-point that was importing the `firebase/storage` path. In this commit we solve this problem, for the case of imports coming from a completely different package, by saying that any file that is outside the package root directory must be an external import and so we do not analyze those files. This does not solve the potential problem of imports between secondary entry-points within a package but so far that does not appear to be a problem. PR Close #30591 |
||
|---|---|---|
| .. | ||
| src | ||
| test | ||
| BUILD.bazel | ||
| README.md | ||
| index.ts | ||
| main-ngcc.ts | ||
README.md
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