angular-docs-cn/packages/compiler-cli/ngcc
George Kalpakas bd6a39c364 fix(ngcc): correctly detect emitted TS helpers in ES5 (#35191)
In ES5 code, TypeScript requires certain helpers (such as
`__spreadArrays()`) to be able to support ES2015+ features. These
helpers can be either imported from `tslib` (by setting the
`importHelpers` TS compiler option to `true`) or emitted inline (by
setting the `importHelpers` and `noEmitHelpers` TS compiler options to
`false`, which is the default value for both).

Ngtsc's `StaticInterpreter` (which is also used during ngcc processing)
is able to statically evaluate some of these helpers (currently
`__assign()`, `__spread()` and `__spreadArrays()`), as long as
`ReflectionHost#getDefinitionOfFunction()` correctly detects the
declaration of the helper. For this to happen, the left-hand side of the
corresponding call expression (i.e. `__spread(...)` or
`tslib.__spread(...)`) must be evaluated as a function declaration for
`getDefinitionOfFunction()` to be called with.

In the case of imported helpers, the `tslib.__someHelper` expression was
resolved to a function declaration of the form
`export declare function __someHelper(...args: any[][]): any[];`, which
allows `getDefinitionOfFunction()` to correctly map it to a TS helper.

In contrast, in the case of emitted helpers (and regardless of the
module format: `CommonJS`, `ESNext`, `UMD`, etc.)), the `__someHelper`
identifier was resolved to a variable declaration of the form
`var __someHelper = (this && this.__someHelper) || function () { ... }`,
which upon further evaluation was categorized as a `DynamicValue`
(prohibiting further evaluation by the `getDefinitionOfFunction()`).

As a result of the above, emitted TypeScript helpers were not evaluated
in ES5 code.

---
This commit changes the detection of TS helpers to leverage the existing
`KnownFn` feature (previously only used for built-in functions).
`Esm5ReflectionHost` is changed to always return `KnownDeclaration`s for
TS helpers, both imported (`getExportsOfModule()`) as well as emitted
(`getDeclarationOfIdentifier()`).

Similar changes are made to `CommonJsReflectionHost` and
`UmdReflectionHost`.

The `KnownDeclaration`s are then mapped to `KnownFn`s in
`StaticInterpreter`, allowing it to statically evaluate call expressions
involving any kind of TS helpers.

Jira issue: https://angular-team.atlassian.net/browse/FW-1689

PR Close #35191
2020-02-21 09:06:46 -08:00
..
src fix(ngcc): correctly detect emitted TS helpers in ES5 (#35191) 2020-02-21 09:06:46 -08:00
test fix(ngcc): correctly detect emitted TS helpers in ES5 (#35191) 2020-02-21 09:06:46 -08:00
BUILD.bazel perf(ivy): reuse prior analysis work during incremental builds (#34288) 2019-12-12 13:11:45 -08:00
README.md refactor(ivy): move ngcc into a higher level folder (#29092) 2019-03-20 14:45:54 -04:00
index.ts refactor(ngcc): add support for asynchronous execution (#32427) 2019-09-09 15:55:13 -04:00
main-ivy-ngcc.ts fix(ngcc): rename the executable from `ivy-ngcc` to `ngcc` (#33140) 2019-10-14 16:29:14 +00:00
main-ngcc.ts fix(ngcc): render legacy i18n message ids by default (#34135) 2019-12-03 10:15:53 -08:00

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