[api-extractor] Exports which shadow built-ins are included in incorrect report variants

[Josmithr]

In cases where API exports are aliased to avoid collisions with built-ins, export statements are surfaced in all API report variants regardless of release tag.

This was not an issue prior to the reportVariants feature, but there are now cases where exports that are aliased to avoid conflicts with built-ins result in export statements being included in reports of incorrect release variants.

See this draft PR for a repro of the issue: #4761

[Josmithr]

@octogonz I'm wondering if you can point me in the right direction here in terms of resolution. I believe the export { Foo_2 as Foo } items end up being included because they are not annotated with a release tag, and the code determining what should belong in the different report variants implicitly treats untagged items as @public. Perhaps those checks need to be more nuanced to account for this situation? Or perhaps in these cases the release tag should be copied along from the underlying (aliased) declaration?

[octogonz]

api-extractor-lib2-test/src/index.ts looks like this:

/**
 * Shadows of built-ins get aliased during rollup, which has resulted in tags being ignored when determining correct
 * output for report variants.
 * @internal
 */
export const performance: Performance = globalThis.performance;

The generated api-extractor-lib2-test.api.md looks like this:

// @internal
const performance_2: Performance;
export { performance_2 as performance }

The bug is that api-extractor-lib2-test.public.api.md gets partially trimmed like this:

export { performance_2 as performance }

[octogonz]

@Josmithr could you build this test project with .d.ts trimming enabled, and determine whether this affects the .d.ts rollup as well? If so, this is a higher priority issue.