[api-extractor] Export aliases lost with `bundledPackages`
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 58/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- nodejs, typescript
- Domain
- developer-experience, tooling
Research direction
Start with the linked bundledPackages-reexport-aliased reproduction and run the documented yarn install and build commands. Compare package-b/api-reports/package-b.api.md and package-b/dist/package-b-public.d.ts with package-a/src/FooInternal.ts and package-a/src/index.ts, then trace bundledPackages alias resolution. Done means Baz uses FooExternal and the ae-forgotten-export warning is absent in both outputs.
Written by the indexing model from the issue text.
Description
[api-extractor] bundledPackages uses a source declaration name instead of its exported alias
Summary
When an aliased API export from a package listed in bundledPackages is referenced, API Extractor uses the original source declaration name when referencing that API from the consuming package. The original name is not part of the dependency's public API, so the generated API model and report contain an incorrect reference and an ae-forgotten-export warning. The incorrect name is also used in the generated declaration rollup.
Repro steps
The minimal reproduction is available at:
https://github.com/Josmithr/api-extractor-playground/tree/bundledPackages-reexport-aliased
-
Clone the reproduction branch.
-
From the repository root, install dependencies and build
package-bwith its dependency:yarn install --frozen-lockfile yarn lerna run build --scope package-b --include-dependencies -
Inspect
packages/package-b/api-reports/package-b.api.mdandpackages/package-b/dist/package-b-public.d.ts.
In package-a, FooInternal is exported from the package entry point as FooExternal:
// package-a/src/FooInternal.ts
export type FooInternal = string;
// package-a/src/index.ts
export { FooInternal as FooExternal } from './FooInternal.js';
package-b lists package-a in bundledPackages and references the public name FooExternal:
import type { FooExternal } from 'package-a';
/** @public */
export type Baz = FooExternal;
Expected result:
The API report should preserve the name exported by package-a:
export type Baz = FooExternal;
Actual result:
The API report uses the private source declaration name and reports it as a forgotten export:
// Warning: (ae-forgotten-export) The symbol "FooInternal" needs to be exported by the entry point index.d.ts
//
// @public
export type Baz = FooInternal;
The public declaration rollup similarly contains:
export declare type Baz = FooInternal;
declare type FooInternal = string;
Details
This appears to occur while API Extractor follows the FooExternal re-export into the bundled package. It resolves the underlying declaration correctly, but uses that declaration's local name (FooInternal) instead of the name exported from the dependency's entry point (FooExternal) when generating references in package-b.
Explicitly re-exporting FooExternal from package-b avoids the issue:
export type { FooExternal } from 'package-a';
export type { Baz } from './Baz.js';
With this re-export, the API report and declaration rollup both use FooExternal, and the ae-forgotten-export warning disappears. This suggests the incorrect name is used specifically when the bundled API is referenced by an exported declaration but is not itself exported from the consumer's entry point.
Standard questions
Please answer these questions to help us investigate your issue more quickly:
| Question | Answer |
|---|---|
@microsoft/api-extractor version? |
7.58.12 |
| Operating system? | Linux x64 (Ubuntu 24.04) |
| API Extractor scenario? | Reporting (.api.md) and rollups (.d.ts) |
| Would you consider contributing a PR? | Possibly, with maintainer guidance |
| TypeScript compiler version? | 5.9.3 |
Node.js version (node -v)? |
v24.14.0 |
- Dominant language
- TypeScript
- Stars
- 6.5k
- Forks
- 708
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 48
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/rushstack
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in microsoft/rushstack
Similar issues
-
clawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
supermomonga/zcode-acp#24 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
growthbook/growthbook#7100 ·
-
triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100