History

Alex Rickabaugh 6d42954327 fix(compiler-cli): remove the concept of an errored trait (#39923 )

Previously, if a trait's analysis step resulted in diagnostics, the trait
would be considered "errored" and no further operations, including register,
would be performed. Effectively, this meant that the compiler would pretend
the class in question was actually undecorated.

However, this behavior is problematic for several reasons:

1. It leads to inaccurate diagnostics being reported downstream.

For example, if a component is put into the error state, for example due to
a template error, the NgModule which declares the component would produce a
diagnostic claiming that the declaration is neither a directive nor a pipe.
This happened because the compiler wouldn't register() the component trait,
so the component would not be recorded as actually being a directive.

2. It can cause incorrect behavior on incremental builds.

This bug is more complex, but the general issue is that if the compiler
fails to associate a component and its module, then incremental builds will
not correctly re-analyze the module when the component's template changes.
Failing to register the component as such is one link in the larger chain of
issues that result in these kinds of issues.

3. It lumps together diagnostics produced during analysis and resolve steps.

This is not causing issues currently as the dependency graph ensures the
right classes are re-analyzed when needed, instead of showing stale
diagnostics. However, the dependency graph was not intended to serve this
role, and could potentially be optimized in ways that would break this
functionality.

This commit removes the concept of an "errored" trait entirely from the
trait system. Instead, analyzed and resolved traits have corresponding (and
separate) diagnostics, in addition to potentially `null` analysis results.
Analysis (but not resolution) diagnostics are carried forward during
incremental build operations. Compilation (emit) is only performed when
a trait reaches the resolved state with no diagnostics.

This change is functionally different than before as the `register` step is
now performed even in the presence of analysis errors, as long as analysis
results are also produced. This fixes problem 1 above, and is part of the
larger solution to problem 2.

PR Close #39923

2020-12-03 13:42:13 -08:00

src

fix(compiler-cli): remove the concept of an errored trait (#39923 )

2020-12-03 13:42:13 -08:00

test

fix(compiler-cli): remove the concept of an errored trait (#39923 )

2020-12-03 13:42:13 -08:00

BUILD.bazel

refactor(ngcc): move sourcemaps into ngtsc (#37114 )

2020-06-22 13:38:47 -07:00

index.ts

refactor(ngcc): move logging code into ngtsc (#37114 )

2020-06-22 13:38:47 -07:00

main-ivy-ngcc.ts

build: update license headers to reference Google LLC (#37205 )

2020-05-26 14:26:58 -04:00

main-ngcc.ts

build: update license headers to reference Google LLC (#37205 )

2020-05-26 14:26:58 -04: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