Command
build
Is this a regression?
The previous version in which this bug was not present was
No response
Description
Found while testing #34106 cc @alan-agius4
When the same name is reached through two export * paths, and each of those files re-exports it by name from a module bundle treats as external (a sibling entry point, or a package like @angular/core), the name is dropped from the FESM bundle and from the .d.ts. The re-export becomes a bare side-effect import. Exit 0, no warning.
Hit on ng-zorro-antd: ng-zorro-antd/i18n loses NZ_DATE_LOCALE, so import { NZ_DATE_LOCALE } from 'ng-zorro-antd/i18n' stops compiling. ng-packagr keeps it.
Minimal Reproduction
projects/lib/src/a.ts: export { InjectionToken } from '@angular/core';
projects/lib/src/b.ts: the same line
projects/lib/src/public-api.ts: export * from './a'; and export * from './b';
- one entry point,
".": "projects/lib/src/public-api.ts"
- build:
fesm2022/lib.mjs and types/lib.d.ts are each a single line, import "@angular/core";
ng-packagr on the same sources emits export { InjectionToken } from '@angular/core'; in both. A consumer gets TS2305 at build time and "does not provide an export named" at runtime.
Exception or Error
Your Environment
@angular/build built from #34106 (005e05ee) with the repo's own bazel build
Angular CLI 22.1.8
Angular 22.1.7
Node 24.16.0
npm 11.13.0
macOS 26.6, 14 cores, 24 GB
Anything else relevant?
It's rolldown, not builder. rolldown 1.2.8 alone, no Angular: an entry that stars a.js and b.js, each doing export { EXT } from 'ext' with ext external, outputs import "ext" with an empty exports list, and reports no warning even with an onwarn handler. Node keeps the name in that shape (the namespace has EXT) and only drops it when the two paths resolve to different bindings, which is the case the spec's ambiguity rule is for.
One export * path survives, and so does one named re-export plus one star. Other names in the same files are unaffected, only the duplicated one is lost.
Command
build
Is this a regression?
The previous version in which this bug was not present was
No response
Description
Found while testing #34106 cc @alan-agius4
When the same name is reached through two
export *paths, and each of those files re-exports it by name from a module bundle treats as external (a sibling entry point, or a package like@angular/core), the name is dropped from the FESM bundle and from the.d.ts. The re-export becomes a bare side-effect import. Exit 0, no warning.Hit on ng-zorro-antd:
ng-zorro-antd/i18nlosesNZ_DATE_LOCALE, soimport { NZ_DATE_LOCALE } from 'ng-zorro-antd/i18n'stops compiling. ng-packagr keeps it.Minimal Reproduction
projects/lib/src/a.ts:export { InjectionToken } from '@angular/core';projects/lib/src/b.ts: the same lineprojects/lib/src/public-api.ts:export * from './a';andexport * from './b';".": "projects/lib/src/public-api.ts"fesm2022/lib.mjsandtypes/lib.d.tsare each a single line,import "@angular/core";ng-packagr on the same sources emits
export { InjectionToken } from '@angular/core';in both. A consumer gets TS2305 at build time and "does not provide an export named" at runtime.Exception or Error
Your Environment
Anything else relevant?
It's rolldown, not builder. rolldown 1.2.8 alone, no Angular: an entry that stars
a.jsandb.js, each doingexport { EXT } from 'ext'withextexternal, outputsimport "ext"with an empty exports list, and reports no warning even with anonwarnhandler. Node keeps the name in that shape (the namespace hasEXT) and only drops it when the two paths resolve to different bindings, which is the case the spec's ambiguity rule is for.One
export *path survives, and so does one named re-export plus one star. Other names in the same files are unaffected, only the duplicated one is lost.