[api-extractor] Export aliases lost with `bundledPackages`
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 58/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- nodejs, typescript
- Lĩnh vực
- developer-experience, tooling
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
[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 |
- Ngôn ngữ chính
- TypeScript
- Star
- 6.5k
- Fork
- 708
- Merge trung bình
- 4 ngày 13 giờ
- Pull request đã merge (30 ngày)
- 62
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/rushstack
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
microsoft/rushstack#5971 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
microsoft/rushstack#5902 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
microsoft/rushstack#5839 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
microsoft/rushstack#5683 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của microsoft/rushstack
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
diegosouzapw/OmniRoute#14869 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 94/100
Maintainer thường phản hồi trong vòng 1 ngày
-
status: waiting triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
freeCodeCamp/freeCodeCamp#70412 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Mend: dependency security vulnerability untriaged
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
opensearch-project/OpenSearch-Dashboards#12816 ·
Maintainer thường phản hồi trong vòng 1 ngày