History

JoostK 3858b26211 refactor(ivy): mark synthetic decorators explicitly (#33362 )

In ngcc's migration system, synthetic decorators can be injected into a
compilation to ensure that certain classes are compiled with Angular
logic, where the original library code did not include the necessary
decorators. Prior to this change, synthesized decorators would have a
fake AST structure as associated node and a made-up identifier. In
theory, this may introduce issues downstream:

1) a decorator's node is used for diagnostics, so it must have position
information. Having fake AST nodes without a position is therefore a
problem. Note that this is currently not a problem in practice, as
injected synthesized decorators would not produce any diagnostics.

2) the decorator's identifier should refer to an imported symbol.
Therefore, it is required that the symbol is actually imported.
Moreover, bundle formats such as UMD and CommonJS use namespaces for
imports, so a bare `ts.Identifier` would not be suitable to use as
identifier. This was also not a problem in practice, as the identifier
is only used in the `setClassMetadata` generated code, which is omitted
for synthetically injected decorators.

To remedy these potential issues, this commit makes a decorator's
identifier optional and switches its node over from a fake AST structure
to the class' name.

PR Close #33362

2019-10-25 09:16:49 -07:00

migration.ts

feat(ngcc): migrate services that are missing @Injectable() (#33362 )

2019-10-25 09:16:49 -07:00

missing_injectable_migration.ts

feat(ngcc): migrate services that are missing @Injectable() (#33362 )

2019-10-25 09:16:49 -07:00

README.md

feat(ivy): ngcc - support ngcc "migrations" (#31544 )

2019-07-23 21:11:40 -07:00

undecorated_parent_migration.ts

style: emove unreachable 'return null' statement (#33174 )

2019-10-16 10:58:38 -04:00

utils.ts

refactor(ivy): mark synthetic decorators explicitly (#33362 )

2019-10-25 09:16:49 -07:00

README.md

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.