[api-extractor] InternalError when analyzing EditorState from draft-js

[octogonz]

@nvh reported an error in issue #949, which on investigation turned out to be a separate issue:

I encountered this error importing the EditorState from draft-js and using it in a class
A minimal reproduction looks like this:

import { EditorState } from "draft-js"
export class Text {
    editorState: EditorState
}

making the editorState private fixes the problem.
Example project:
registerd-as-non-imported.zip
Reproduction steps:

The error message was:

The symbol EditorState is being imported after it was already registered as non-imported

[octogonz]

Inside the typings for @types\draft-js\index.d.ts we have this:

export as namespace Draft;
declare namespace Draft {
    namespace Model {
        namespace ImmutableData {
            class EditorState extends Record {
                // ...
            }
        }
    }
}

import EditorState = Draft.Model.ImmutableData.EditorState;

export {
    EditorState
};

Initially I thought this was another instance of the export { x } construct (issue #663), however it seems to be a more mundane problem. In AstSymbolTable.ts, the compiler's isSourceFileFromExternalLibrary() API is returning false for @types\draft-js\index.d.ts which causes a full analysis of this unsupported construct.

        // If the file is from a package that does not support AEDoc, then we process the
        // symbol itself, but we don't attempt to process any parent/children of it.
        const followedSymbolSourceFile: ts.SourceFile = followedSymbol.declarations[0].getSourceFile();
        if (this._program.isSourceFileFromExternalLibrary(followedSymbolSourceFile)) {
          if (!this._packageMetadataManager.isAedocSupportedFor(followedSymbolSourceFile.fileName)) {
            nominal = true;
          }
        }

Whereas if nominal = true then the problematic construct would not be analyzed and the API extraction would be successful.

It seems that the compiler's isSourceFileFromExternalLibrary() doesn't do what I thought it did, since @types/draft-js sure seems like an "external library". Perhaps we need to revert to the earlier approach relying on isAedocSupportedFor --> PackageJsonLookup to determine whether a project belongs to the current project or not... This API was introduced in PR microsoft/TypeScript#12054

@DanielRosenwasser FYI

[octogonz]

This is working now in my branch for PR #1002

It makes the analysis accurate so that we can simply test whether followAliasesResult.astImport is defined or not. If so, then the symbol is from an external package.

[octogonz]

Fixed in #1002