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 |
||
|---|---|---|
| .. | ||
| animations | ||
| bazel | ||
| benchpress | ||
| common | ||
| compiler | ||
| compiler-cli | ||
| core | ||
| docs | ||
| elements | ||
| examples | ||
| forms | ||
| http | ||
| language-service | ||
| platform-browser | ||
| platform-browser-dynamic | ||
| platform-server | ||
| platform-webworker | ||
| platform-webworker-dynamic | ||
| private/testing | ||
| router | ||
| service-worker | ||
| upgrade | ||
| zone.js | ||
| BUILD.bazel | ||
| README.md | ||
| empty.ts | ||
| goog.d.ts | ||
| license-banner.txt | ||
| system.d.ts | ||
| tsconfig-build.json | ||
| tsconfig-test.json | ||
| tsconfig.json | ||
| types.d.ts | ||
README.md
Angular
The sources for this package are in the main Angular repo. Please file issues and pull requests against that repo.
License: MIT