Fix codefix-triggered auto import of aliased exports

[andrewbranch]

Fixes #59583

[iisaduan]

Do we need an extra importadder function? It seems like this could be done by doing the tryGetAutoImportableReference... call/logic from within addImportFromExportedSymbol (or an update to exportinfomap?). The functions seem too similar to justify a new one, this function one skips a lot of the resolving in the existing function, and any other codefix that tries to import Alias from a symbol reference still crashes after this PR.

(I also think this is an issue with export aliases in general, not just types)

[iisaduan]

"replacement" is a little confusing to me--does this refer to export aliases in general?

[andrewbranch]

No, it refers to the fact that an ImportType has been replaced by a TypeReference plus a top-level import.

[andrewbranch]

@iisaduan what’s happening here is that the add-missing-members codefix generates code like

someMethod(p: import("./one").SomeType, q: import("./two").default) {}

which first gets transformed into

someMethod(p: SomeType, q: BetterNameForDefault) {}

and then we ask to auto-import the symbols for those types. But we were only passing the symbols in, which means we were losing important pieces of information:

1. The imports we generate must expose SomeType and BetterNameForDefault as the resulting identifiers.
2. The export names we should be looking to match are SomeType and default.
3. The symbols must be types, so are valid to be imported as type-only
4. The file we’re importing into is TypeScript

addImportFromExportedSymbol doesn’t receive any of that information as parameters and does a bunch of work to determine it, and wasn’t always coming up with the right result. I first tried to expand the existing signature, but it was getting unwieldy and felt like it was trying to stretch it too far. But you’re right; extracting it out meant I didn’t fix a similar crash from occurring in the addImportFromExportedSymbol code path 😕