[api-extractor] Fix internal error when importing a re-exported namespace by name

[lukasIO]

Summary

Fixes #4963:

Internal Error: The "..." symbol has a ts.SyntaxKind.SourceFile declaration which is not (yet?) supported by API Extractor

This happens when a dependency re-exports an entire module as a namespace, e.g.:

// foo
export * as utils from './utils/index.js';

and a downstream package imports that namespace by name and references a type within it:

// bar
import { utils } from 'foo';
export const aTypedObject: utils.FooType = { flag: false };

When resolving the utils import, ExportAnalyzer._fetchAstImport() follows the alias chain, which lands on the re-exported module's source file symbol. _fetchAstSymbol() then throws because a SourceFile is not a supported declaration kind.

Details

In _fetchAstImport(), skip fetching an AstSymbol when the followed import symbol represents an entire module (a ValueModule whose declaration is a SourceFile). There is no AstSymbol to associate with a whole module, so we leave astImport.astSymbol undefined — exactly what already happens for import * as ns from '...' star imports (which pass importSymbol = undefined). The import is still emitted correctly in the rollup.

How it was tested

• Added the importExternalReexportedNamespace scenario to api-extractor-scenarios (with a supporting Lib2ReexportedNamespace re-export in api-extractor-lib2-test), which imports a re-exported namespace from an external package and references a type within it.
• Confirmed the new scenario reproduces the crash on main and passes with the fix.
• rush rebuild -t api-extractor-scenarios is green (no regressions in existing scenarios).
• @microsoft/api-extractor unit tests pass (61/61).

Impacted documentation

[lukasIO]

@microsoft-github-policy-service agree company="LiveKit"