ed7aa1c3e5
When ngtsc encounters a reference to a type (for example, a Component type listed in an NgModule declarations array), it traces the import of that type and attempts to determine the best way to refer to it. In the event the type is defined in the same file where a reference is being generated, the identifier of the type is used. If the type was imported, ngtsc has a choice. It can use the identifier from the original import, or it can write a new import to the module where the type came from. ngtsc has a bug currently when it elects to rely on the user's import. When writing a .d.ts file, the user's import may have been elided as the type was not referred to from the type side of the program. Thus, in .d.ts files ngtsc must always assume the import may not exist, and generate a new one. In .js output the import is guaranteed to still exist, so it's preferable for ngtsc to continue using the existing import if one is available. This commit changes how @angular/compiler writes type definitions, and allows it to use a different expression to write a type definition than is used to write the value. This allows ngtsc to specify that types in type definitions should always be imported. A corresponding change to the staticallyResolve() Reference system allows the choice of which type of import to use when generating an Expression from a Reference. PR Close #25080
Angular
Angular is a development platform for building mobile and desktop web applications using Typescript/JavaScript and other languages.
Quickstart
Changelog
Learn about the latest improvements.
Want to help?
Want to file a bug, contribute some code, or improve documentation? Excellent! Read up on our guidelines for contributing and then check out one of our issues in the hotlist: community-help.