6338cb7b3b
Currently when application source code references e.g. an NgModule that points to references that aren't available, the compiler will break at runtime without any actionable/reasonable error. This could happen for example when a library is referenced in code, but the library is simply not available in the `node_modules`. Clearly, TypeScript would issue import diagnostics here, but the Angular compiler shouldn't break fatally. This is useful for migrations which may run against projects which aren't fully compilable. The compiler handles this fine in all cases, except when processing `.d.ts` currently... and the runtime exception invalides all other information of the program etc. This commit fixes this by degrading such unexpected cases for `.d.ts` metadata reading to be handled gracefully. This matches existing logic where the `.d.ts` doesn't necessarily match the "expecation"/"expected format". The worst case is that the Angular compiler will not have type information for some directives of e.g. a library that just isn't installed in local `node_modules`; compared to magical errors and unexpected runtime behavior. PR Close #58515 |
||
|---|---|---|
| .. | ||
| common | ||
| component | ||
| directive | ||
| ng_module | ||
| src | ||
| test | ||
| BUILD.bazel | ||
| index.ts | ||
| README.md | ||
What is the 'annotations' package?
This package implements compilation of Angular-annotated classes - those with @Component, @NgModule, etc. decorators. (Note that the compiler uses 'decorator' and 'annotation' interchangeably, despite them having slightly different semantics).
The 'transform' package of the compiler provides an abstraction for a DecoratorHandler, which defines how to compile a class decorated with a particular Angular decorator. This package implements a DecoratorHandler for each Angular type. The methods of these DecoratorHandlers then allow the rest of the compiler to process each decorated class through the phases of compilation.
Anatomy of DecoratorHandlers
Each handler implemented here performs some similar operations:
- It uses the
PartialEvaluatorto resolve expressions within the decorator metadata or other decorated fields that need to be understood statically. - It extracts information from constructors of decorated classes which is required to generate dependency injection instructions.
- It reports errors when developers have misused or misconfigured the decorators.
- It populates registries that describe decorated classes to the rest of the compiler.
- It uses those same registries to understand decorated classes within the context of the compilation (for example, to understand which dependencies are used in a given template).
- It creates
SemanticSymbols which allow for accurate incremental compilation when reacting to input changes. - It builds metadata objects for
@angular/compilerwhich describe the decorated classes, which can then perform the actual code generation.
Since there is significant overlap between DecoratorHandler implementations, much of this functionality is implemented in a shared 'common' sub-package.