fix(compiler-cli): incorrect metadata bundle for multiple unnamed re-exports #29360
+22
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…exports Currently if an Angular library has multiple unnamed module re-exports, NGC will generate incorrect metdata if the project is using the flat-module bundle option. e.g. _public-api.ts_ ```ts export * from '@mypkg/secondary1'; export * from '@mypkg/secondary2'; ``` There are clearly two unnamed re-exports in the `public-api.ts` file. NGC right now accidentally overwrites all previous re-exports with the last one. Resulting in the generated metadata only containing a reference to `@mypkg/secondary2`. This is problematic as it is common for primary library entry-points to have multiple re-exports (e.g. Material re-exporting all public symbols; or flex-layout exporting all public symbols from their secondary entry-points). Currently Angular Material works around this issue by manually creating a metadata file that declares the re-exports from all unnamed re-exports. (see: https://github.com/angular/material2/blob/master/tools/package-tools/build-release.ts#L78-L85) This workaround works fine currently, but is no longer easily integrated when building the package output with Bazel. In order to be able to build such libraries with Bazel (Material/flex-layout), we need to make sure that NGC generates the proper flat-module metadata bundle.
devversion
added
area: core
2 tasks
alexeagle
approved these changes
Mar 17, 2019
matsko
pushed a commit
that referenced
this pull request
Mar 18, 2019
…exports (#29360) Currently if an Angular library has multiple unnamed module re-exports, NGC will generate incorrect metdata if the project is using the flat-module bundle option. e.g. _public-api.ts_ ```ts export * from '@mypkg/secondary1'; export * from '@mypkg/secondary2'; ``` There are clearly two unnamed re-exports in the `public-api.ts` file. NGC right now accidentally overwrites all previous re-exports with the last one. Resulting in the generated metadata only containing a reference to `@mypkg/secondary2`. This is problematic as it is common for primary library entry-points to have multiple re-exports (e.g. Material re-exporting all public symbols; or flex-layout exporting all public symbols from their secondary entry-points). Currently Angular Material works around this issue by manually creating a metadata file that declares the re-exports from all unnamed re-exports. (see: https://github.com/angular/material2/blob/master/tools/package-tools/build-release.ts#L78-L85) This workaround works fine currently, but is no longer easily integrated when building the package output with Bazel. In order to be able to build such libraries with Bazel (Material/flex-layout), we need to make sure that NGC generates the proper flat-module metadata bundle. PR Close #29360
wKoza
pushed a commit
to wKoza/angular
that referenced
this pull request
Apr 17, 2019
…exports (angular#29360) Currently if an Angular library has multiple unnamed module re-exports, NGC will generate incorrect metdata if the project is using the flat-module bundle option. e.g. _public-api.ts_ ```ts export * from '@mypkg/secondary1'; export * from '@mypkg/secondary2'; ``` There are clearly two unnamed re-exports in the `public-api.ts` file. NGC right now accidentally overwrites all previous re-exports with the last one. Resulting in the generated metadata only containing a reference to `@mypkg/secondary2`. This is problematic as it is common for primary library entry-points to have multiple re-exports (e.g. Material re-exporting all public symbols; or flex-layout exporting all public symbols from their secondary entry-points). Currently Angular Material works around this issue by manually creating a metadata file that declares the re-exports from all unnamed re-exports. (see: https://github.com/angular/material2/blob/master/tools/package-tools/build-release.ts#L78-L85) This workaround works fine currently, but is no longer easily integrated when building the package output with Bazel. In order to be able to build such libraries with Bazel (Material/flex-layout), we need to make sure that NGC generates the proper flat-module metadata bundle. PR Close angular#29360
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently if an Angular library has multiple unnamed module re-exports, NGC will
generate incorrect metadata if the project is using the flat-module bundle option.
e.g.
public-api.ts
There are clearly two unnamed re-exports in the
public-api.tsfile. NGC right nowaccidentally overwrites all previous re-exports with the last one. Resulting in the
generated metadata only containing a reference to
@mypkg/secondary2.This is problematic as it is common for primary library entry-points to have
multiple re-exports (e.g. Material re-exporting all public symbols; or flex-layout
exporting all public symbols from their secondary entry-points).
Currently Angular Material works around this issue by manually creating
a metadata file that declares the re-exports from all unnamed re-exports.
(see: https://github.com/angular/material2/blob/master/tools/package-tools/build-release.ts#L78-L85)
This workaround works fine currently, but is no longer easily integrated when
building the package output with Bazel. In order to be able to build such
libraries with Bazel (Material/flex-layout), we need to make sure that NGC
generates the proper flat-module metadata bundle.