Fix type-only imports in interface 'extends' and import=/export=

[andrewbranch]

• Fixes a bug I discovered while working on this where errors for using a transitively type-only alias didn’t appear in editors depending on what files are open (because alias resolution happened in a different order than in tsc)—tested in the added unit test.
• Fixes import type can't be used with interface extends #36478
• Fixes Type-only import can be used as value after 'import =' #36466
  • Disallows import aliases referencing type-only names
  • Fixes ImportEqualsDeclarations and ExportAssignments referencing type-only names (adds appropriate error for usage of alias in JS-emitting positions)

[sandersn]

Some initial comments. I'm still reading the checker.ts changes.

[sandersn]

I would declare a new variable just because I hate mutation so much:

Suggested change

	resolvesToSymbol = resolvesToSymbol.exports?.get(InternalSymbolName.ExportEquals) ?? resolvesToSymbol;
	const resolved = resolvesToSymbol.exports?.get(InternalSymbolName.ExportEquals) ?? resolvesToSymbol;

Not sure about the name.

[sandersn]

Are there other kinds of aliases we might have to manually follow the same way as import =? This seems like a slightly odd place to manually get ExportEquals out of the exports, although I could be wrong.

[andrewbranch]

Are there other kinds of aliases we might have to manually follow the same way as import =?

The answer is almost definitely “no,” but I’ve been struggling to concisely explain why for too long at this point, which makes me realize that the reason I’m confident that I’m right is mostly because of thorough test coverage.

[sandersn]

Lots of questions and comments. I can't tell how multi-part chains are getting followed from reading the code.

[sandersn]

this call pair happens quite a few times. I think it should be extracted, perhaps into markSymbolOfAliasDeclarationIfResolvesToTypeOnly itself. I can't tell if it's possible and easy to regularize the other calls to accommodate the 1-export 2-resolved pattern.

[andrewbranch]

I had the same thought when reviewing my own PR this morning, but stopped when I couldn’t come up with a satisfying name to add more logic to a function that already has a monstrous name. Any suggestions?

[andrewbranch]

Combined all three type-only checks (1. declaration is marked type-only; 2. immediate alias is marked type-only; 3. final alias is marked type-only) into one markSymbolOfAliasDeclarationIfTypeOnly call

[weswigham]

export default <expr> behaves a lot like export = <expr> and probably also needs a test.

[andrewbranch]

@weswigham like this one? The large majority of type-only tests already existed. There are also some new export default tests covered in the unit test.

[weswigham]

I was thinking like this one but with export default in place of export = (and default imports in place of namespace imports)

[bolinfest]

I just commented on #36478 as I don't think this fixes the issue when the type is another level deep because it appears I can do this:

import type * as monaco from "monaco-editor";

interface MyViewZone extends monaco.IRange {
  marginDomNode: HTMLElement;
}

but not this:

import type * as monaco from "monaco-editor";

interface MyViewZone extends monaco.editor.IViewZone {
  marginDomNode: HTMLElement;
}

[bolinfest]

Ah, though as a workaround I can do:

import type * as monaco from "monaco-editor";
type IViewZone = monaco.editor.IViewZone;

interface MyViewZone extends IViewZone {
  marginDomNode: HTMLElement;
}