[api-extractor] Add support for api report and documentation for multiple entry points

[Feiyang1]

Implements https://github.com/microsoft/rushstack/issues/1596 More precisely it implements level 1 described in https://github.com/microsoft/rushstack/issues/1596#issuecomment-546790721 by @octogonz

Main changes:

• Add additionalEntryPoints field to the config file
• Generate multiple entry points in api.json file if additionalEntryPoints is defined
• Generate multiple API report files, one for each entry point in the package
• Generate documentation for multiple entry points if additionalEntryPoints is defined

Important limitation: Entry points don't share symbols. For example, if package A has 2 entry points, packageA and packageA/internal, where packageA reexports a symbol from packageA/internal:

packageA

export { internalFunction } from './internal';

export function bar() {};

packageA/internal

export function internalFunction() {};

In the api.json file, internalFunction() will appear twice as separate entities for packageA and packageA/internal respectively. As a result, documenter generates 2 files for internalFunction().

I spent a few hours trying to make entry points to share symbols, but made little progress. I think it might require large refactoring beyond my knowledge of the codebase. Though not sharing symbols between entry points is not ideal, it's currently not a deal breaker for me.

Please let me know if the approach doesn't look reasonable. Thanks!

[Feiyang1]

@octogonz When you have a moment, can you please take a look? Thanks!

[octogonz]

When you have a moment, can you please take a look? Thanks!

Thanks for following up. This is an exciting contribution! I apologize I haven't been able to review it yet; this has been a busy sprint for me personally, and there's been a significant increase in new contributions for Rush Stack projects this summer. We're having trouble keeping up with it.

[Feiyang1]

Gentle ping @octogonz

[MathBunny]

+1 The project I am currently working on would also benefit from this feature; when there's bandwidth @octogonz 🙂

[octogonz]

+1 The project I am currently working on would also benefit from this feature; when there's bandwidth

I think my company just encountered a similar need heheh. I will try to get to this soon.

[hiranya911]

Hey @Feiyang1. Thanks for putting this together. Does this handle the case where one entrypoint just uses the types exported by another entrypoint, without necessarily re-exporting it?

For example:

// module A
import { Foo } from './B';

export interface MyInterface {
  foo: Foo;
}

// module B
export interface Foo {
  field: string;
}

Assuming A and B are separate entrypoints, notice that A uses a type declared in B without re-exporting it. Is this adequately handled?

[Feiyang1]

@hiranya911 I believe you will get a warning that Foo is part of the public interface, but is not exported. Everything else(API report, documentation) should just work.

[ava-jr]

+1 from me, this is just what I need to make api-extractor viable in our tool chain

[mkilpatrick]

Bump on this PR. Would love to see it merged!

[dzearing]

@octogonz, @iclanton - ping on this one. Been open for a while.

I don't know if it's still valid. Ideally this pr would respect package.json exports map and read types from that, which would encourage package owners that support multiple entries to document them properly.