History

Alex Rickabaugh ecffc3557f perf(compiler-cli): perform template type-checking incrementally (#36211 )

This optimization builds on a lot of prior work to finally make type-
checking of templates incremental.

Incrementality requires two main components:
- the ability to reuse work from a prior compilation.
- the ability to know when changes in the current program invalidate that
  prior work.

Prior to this commit, on every type-checking pass the compiler would
generate new .ngtypecheck files for each original input file in the program.

1. (Build #1 main program): empty .ngtypecheck files generated for each
   original input file.

2. (Build #1 type-check program): .ngtypecheck contents overridden for those
   which have corresponding components that need type-checked.

3. (Build #2 main program): throw away old .ngtypecheck files and generate
   new empty ones.

4. (Build #2 type-check program): same as step 2.

With this commit, the `IncrementalDriver` now tracks template type-checking
_metadata_ for each input file. The metadata contains information about
source mappings for generated type-checking code, as well as some
diagnostics which were discovered at type-check analysis time. The actual
type-checking code is stored in the TypeScript AST for type-checking files,
which is now re-used between programs as follows:

1. (Build #1 main program): empty .ngtypecheck files generated for each
   original input file.

2. (Build #1 type-check program): .ngtypecheck contents overridden for those
   which have corresponding components that need type-checked, and the
   metadata registered in the `IncrementalDriver`.

3. (Build #2 main program): The `TypeCheckShimGenerator` now reuses _all_
   .ngtypecheck `ts.SourceFile` shims from build #1's type-check program in
   the construction of build #2's main program. Some of the contents of
   these files might be stale (if a component's template changed, for
   example), but wholesale reuse here prevents unnecessary changes in the
   contents of the program at this point and makes TypeScript's job a lot
   easier.

4. (Build #2 type-check program): For those input files which have not
   "logically changed" (meaning components within are semantically the same
   as they were before), the compiler will re-use the type-check file
   metadata from build #1, and _not_ generate a new .ngtypecheck shim.
   For components which have logically changed or where the previous
   .ngtypecheck contents cannot otherwise be reused, code generation happens
   as before.

PR Close #36211

2020-05-05 18:40:42 -07:00

src

perf(compiler-cli): perform template type-checking incrementally (#36211 )

2020-05-05 18:40:42 -07:00

test

perf(ngcc): speed up the getBasePaths() computation (#36881 )

2020-05-04 12:50:02 -07:00

BUILD.bazel

fix(ngcc): use path-mappings from tsconfig in dependency resolution (#36180 )

2020-03-24 10:16:12 -07:00

index.ts

refactor(ngcc): move PathMappings to separate file to avoid circular dependency (#36626 )

2020-04-29 14:28:26 -07: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): provide a unique exit code for timeouts (#36838 )

2020-05-01 09:52:09 -07:00

README.md

refactor(ivy): move ngcc into a higher level folder (#29092 )

2019-03-20 14:45:54 -04: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