ngcc: re-export private NgModule declarations#26906
Conversation
|
You can preview fd6cbc6 at https://pr26906-fd6cbc6.ngbuilds.io/. |
fd6cbc6 to
1ae87b6
Compare
|
You can preview 1ae87b6 at https://pr26906-1ae87b6.ngbuilds.io/. |
1ae87b6 to
159b98e
Compare
159b98e to
86732c9
Compare
|
You can preview 86732c9 at https://pr26906-86732c9.ngbuilds.io/. |
86732c9 to
9ba0954
Compare
|
You can preview 9ba0954 at https://pr26906-9ba0954.ngbuilds.io/. |
9ba0954 to
16fa15f
Compare
|
You can preview 16fa15f at https://pr26906-16fa15f.ngbuilds.io/. |
There was a problem hiding this comment.
Yes, being less strict here resolves an issue for me as well 👍
There was a problem hiding this comment.
Great! I think I am done with refactoring this. Ready for a proper review.
16fa15f to
a75a204
Compare
|
You can preview a75a204 at https://pr26906-a75a204.ngbuilds.io/. |
|
@alxhub, @JoostK & @gkalpak ready for a review. My big concern here is that there is no integration test of this functionality. I have checked that it works manually for me. I would like to add a proper integration test, but I have been battling to move integration tests to use Bazel, and I think this is good enough to land now and then add the tests once Bazel tests are working properly. |
|
You can preview ef5fafc at https://pr26906-ef5fafc.ngbuilds.io/. |
|
You can preview c9e8d33 at https://pr26906-c9e8d33.ngbuilds.io/. |
The `NgModuleDecoratorHandler` can now register all the references that it finds in the `NgModule` metadata, such as `declarations`, `imports`, `exports` etc. This information can then be used by ngcc to work out if any of these references are internal only and need to be manually exported from a library's entry-point. PR Close #26906
There are a number of variables that need to be passed around the program, in particular to the renderers, which benefit from being stored in well defined objects. The new `EntryPointBundle` structure is a specific format of an entry-point and contains the compiled `BundleProgram` objects for the source and typings, if appropriate. This change helps with future refactoring, where we may need to add new properties to this object. It allows us to maintain more stable APIs between the constituent parts of ngcc, rather than passing lots of primitive values around throughout the program. PR Close #26906
This analyzer searches the source for declared classes that are not exported publicly from the entry-point. PR Close #26906
Ngcc will now render additional exports for classes that are referenced in `NgModule` decorated classes, but which were not publicly exported from an entry-point of the package. This is important because when ngtsc compiles libraries processed by ngcc it needs to be able to publcly access decorated classes that are referenced by `NgModule` decorated classes in order to build templates that use these classes. Doing this re-exporting is not without its risks. There are chances that the class is not exported correctly: there may already be similarly named exports from the entry-point or the class may be being aliased. But there is not much more we can do from the point of view of ngcc to workaround such scenarios. Generally, packages should have been built so that this approach works. PR Close #26906
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information