Alias for module.exports.x = x

[sandersn]

This fixes #40155 in a surprisingly small amount of code.

@weswigham any idea how alias resolution Just Works in the rest of the compiler?

[sandersn]

I added m here because otherwise the generated code was export { unknown as methods }, which is correct, and better than before, but caused an error in the emitted .d.ts that I didn't want.

[weswigham]

Once it's bound as an alias, once getTargetOfAliasDeclaration has an appropriate implementation for the alias declaration, everything should be lit up (except maybe some syntax remapping in the declaration serializer).

In the case of a lot of JS stuff, I added implementations for some things to getTargetOfAliasDeclaration even though they weren't yet bound as aliases so I could pretend they were in the declaration serializer (because the checker fallback lookup in JS often works a lot like an alias).

[weswigham]

You'll probably also wanna add some module.exports.x = a.b.c and module.exports = class Foo {} style tests, too (since those should make aliases, too!)

[weswigham]

While isIdentifier is very narrow and works, we should probably reuse the isAliasableExpression condition we use for exportAssignmentIsAlias which is used for bindExportAssignment, so the rules for what gets an alias vs not is consistent for all possibly-an-alias expressions.

[sandersn]

Note that isAliasableExpression is isEntityNameExpression || isClassExpression; previously module.x = class { } was not handled as aan alias, but doing so is more consistent. I'm going to see whether it breaks any of our tests.

[sandersn]

Updated tests, it was an improvement overall. (But it does not, on its own, make module.exports.x = NS.C work; I'm looking to see what else needs to happen)

[sandersn]

OK, the newest commit treats any aliasable expression as an alias. This applies to classes, too, so I removed the ad-hoc code that was in the binder before. I think this is an improvment.

[weswigham]

Looks pretty good! It might be worth testing having some references to K inside K's body's types, just to check that local names of aliased things are getting serialized correctly in declaration emit.

[weswigham]

Hm - can we have an issue/update to get this to emit as

declare namespace NS {
    class _K {
      values(): void;
    }
    export {_K as K};
}
import _K = NS.K;
export {_K as K};

? That'd be more precise, and is reasonable enough given the (alias) symbol shape of the input, IMO. I imagine the serializer just isn't handling the NS nesting well right now, and it is falling back to a var-based emit, even though it all uses alias symbols.

[sandersn]

#40479

[sandersn]

Adding return new NS.K() inside the nested class's method ends up serialising the return type as any. =( I'm going to go see why.

Edit: Works in the non-nested case, though.