Re-export of multiple secondary entry points can lead to conflicts in naming.

[zbream]

Type of Issue

[X] Bug Report
[X] Feature Request

Description

I am attempting to migrate a component library to use secondary entry points, Angular Material style. As a migration strategy, I would like to re-export each secondary entry point in the root, so consumers can use either style.

This generally works fine. However, if more than one of the secondary entry points has some internal module (not exported through that entry point's public-api), I receive the following error:

------------------------------------------------------------------------------
Building entry point 'my-library'
------------------------------------------------------------------------------
× Compiling TypeScript sources through NGC
ERROR: projects/my-library/src/public-api.ts:6:1 - error TS2308: Module 'my-library/secondary-one' has already exported a member named 'ɵa'. Consider explicitly re-exporting to resolve the ambiguity.

6 export * from 'my-library/secondary-two';
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

An unhandled exception occurred: projects/my-library/src/public-api.ts:6:1 - error TS2308: Module 'my-library/secondary-one' has already exported a member named 'ɵa'. Consider explicitly re-exporting to resolve the ambiguity.

6 export * from 'my-library/secondary-two';
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note that I'm building the lib with ViewEngine for distribution on NPM. Building the lib with Ivy works just fine.

It appears that, for each entry point, @angular/compiler-cli will expose the "internal" modules by running them through a newPrivateName() function that outputs names incrementally (ɵa, ɵb, and so on). You can actually see these in the incomplete build artifacts of the secondary entry points:

// dist/my-library/secondary-one/my-library-secondary-one.d.ts

/**
 * Generated bundle index. Do not edit.
 */
export * from './public-api';
export { SecondaryOneInternalService as ɵa } from './lib/secondary-one-internal.service';

// dist/my-library/secondary-two/my-library-secondary-two.d.ts

/**
 * Generated bundle index. Do not edit.
 */
export * from './public-api';
export { SecondaryTwoInternalService as ɵa } from './lib/secondary-two-internal.service';

Unfortunately, since each entry point starts from ɵa, these names will conflict when ng-packagr gets to the root entry point that re-exports them all. Looking for input on how to resolve this, without exposing these internal modules to consumers.

How To Reproduce

https://github.com/zbream/issue-packagr-secondary-reexport

This repo demonstrates the problem. Each entry point has two services, only one of which is publicly exposed. The root entry point re-exports both entry points.

Pull the code, npm i, then ng build my-library --prod . You'll see the error when the root entry point is built.

Expected Behaviour

The build should work successfully, allowing consumers to import from either my secondary entry points or directly from the root.

One idea I had was if I could set flatModulePrivateSymbolPrefix for each entry-point of the package. This adjusts the naming used in newPrivateName() of the compiler. Unfortunately, we don't have access to set this option on a per-entrypoint basis.

1. Perhaps this is something that ng-packagr could generate automatically and uniquely based on the entry point ID here?
2. Perhaps ng-packagr could expose this setting on ng-package.json for each entry point to set manually?

Version Information

$ node_modules/.bin/ng-packagr --version
ng-packagr:            11.2.4
@angular/compiler:     11.2.5
rollup:                2.38.4
typescript:            4.1.5