02bab8cf90
One of the compiler's tasks is to enumerate the exports of a given ES
module. This can happen for example to resolve `foo.bar` where `foo` is a
namespace import:
```typescript
import * as foo from './foo';
@NgModule({
directives: [foo.DIRECTIVES],
})
```
In this case, the compiler must enumerate the exports of `foo.ts` in order
to evaluate the expression `foo.DIRECTIVES`.
When this operation occurs under ngcc, it must deal with the different
module formats and types of exports that occur. In commonjs code, a problem
arises when certain exports are downleveled.
```typescript
export const DIRECTIVES = [
FooDir,
BarDir,
];
```
can be downleveled to:
```javascript
exports.DIRECTIVES = [
FooDir,
BarDir,
```
Previously, ngtsc and ngcc expected that any export would have an associated
`ts.Declaration` node. `export class`, `export function`, etc. all retain
`ts.Declaration`s even when downleveled. But the `export const` construct
above does not. Therefore, ngcc would not detect `DIRECTIVES` as an export
of `foo.ts`, and the evaluation of `foo.DIRECTIVES` would therefore fail.
To solve this problem, the core concept of an exported `Declaration`
according to the `ReflectionHost` API is split into a `ConcreteDeclaration`
which has a `ts.Declaration`, and an `InlineDeclaration` which instead has
a `ts.Expression`. Differentiating between these allows ngcc to return an
`InlineDeclaration` for `DIRECTIVES` and correctly keep track of this
export.
PR Close #32129
ngcc migrations
There are some cases where source code needs to be migrated before ngtsc can compile it correctly.
For example, there are cases where ngtsc expects directives need to be explicitly attached to classes, whereas previously they were not required.
There are two ways this can happen:
- in a project being developed, the code can be migrated via a CLI schematic.
- in a package already published to npm, the code can be migrated as part of the ngcc compilation.
To create one of these migrations for ngcc, you should implement the Migration interface and add
an instance of the class to the DecorationAnalyzer.migrations collection.
This folder is where we keep the Migration interface and the implemented migrations.
Each migration should have a unit test stored in the ../../test/migrations directory.