[api-extractor] Symbols with multiple exports are not modeled in .api.json

[octogonz]

Is this a feature or a bug?

• [ ] Feature
• [x] Bug

Please describe the actual behavior.

In the test case api-extractor-scenarios/etc/test-outputs/exportDuplicate, we have code like this:

/** @internal */
declare class A {
}
export { A as B }
export { A as C }

/** @public */
declare class X {
}
export { X }
export { X as Y }

Expected: The .api.json file should have entries for all the exports B, C, X, and Y.

Actual: The .api.json file contains only X.

It's not a big deal to be missing a few aliased names, but it's not good for A to be completely missing from the docs.

This situation can arise e.g. if an API is renamed, and the old name is preserved for compatibility.

[octogonz]

From a documentation standpoint, we'd much prefer for this:

declare class A {
}
export { A as B }
export { A as C }

...to be recast like this:

// The "primary" declaration
export declare class B {
}

// The "alias"
export { B as C }

The .d.ts rollup considers these two snippets to be equivalent, because A is a local and that has no bearing on the runtime signature of the package.

But A is really awkward to handle in the documentation. API Extractor doesn't want to document unexported types, because philosophically if a type is important enough to publish website documentation for, then there should be way to import that type.

I suppose we could arbitrarily choose the name that comes first alphabetically, and then provide a TSDoc tag to override that default (@primaryAlias?).