Skip to content

Missing import code fix - include export assignment properties when looking for module exports #17376

Merged
minestarks merged 3 commits into
microsoft:masterfrom
minestarks:fix13377
Jul 26, 2017
Merged

Missing import code fix - include export assignment properties when looking for module exports #17376
minestarks merged 3 commits into
microsoft:masterfrom
minestarks:fix13377

Conversation

@minestarks
Copy link
Copy Markdown
Member

Fixes #13377

@minestarks minestarks requested review from amcasey and aozgaa July 24, 2017 19:50
@minestarks minestarks changed the title Include export assignment properties when looking for module exports Missing import code fix - include export assignment properties when looking for module exports Jul 24, 2017
Comment thread src/compiler/checker.ts Outdated
if (symbolTable) {
let symbol = symbolTable.get(memberName);
if (!symbol) {
const exportEquals = resolveExternalModuleSymbol(moduleSymbol);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The export properties don't obviously depend on symbolTable. Is there a reason they're not checked if symbolTable is undefined? It looks like getExportsAndPropertiesOfModule, above, doesn't have this restriction, but it may simply be missing an optimization.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also seems like the first attempt (i.e. the exports) could be attempted by calling tryGetMemberInModuleExports.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, we could merge the APIs and pass a flag.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point, I'll keep the functions separate in the interest of keeping the public API stable. I am changing the code to have this one call tryGetMemberInModuleExports

Comment thread src/compiler/types.ts

tryGetMemberInModuleExports(memberName: string, moduleSymbol: Symbol): Symbol | undefined;
/** Unlike `tryGetMemberInModuleExports`, this includes properties of an `export =` value. */
/* @internal */ tryGetMemberInModuleExportsAndProperties(memberName: string, moduleSymbol: Symbol): Symbol | undefined;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why internal?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that this goes hand in hand with getExportsAndPropertiesOfModule and that one's internal


// check exports with the same name
const exportSymbolWithIdenticalName = checker.tryGetMemberInModuleExports(name, moduleSymbol);
const exportSymbolWithIdenticalName = checker.tryGetMemberInModuleExportsAndProperties(name, moduleSymbol);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this check be skipped if name is "default"?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, I don't think name can legally be "default". Will add a comment to clarify.


// @Filename: foo.ts
//// interface MyStatic {
//// bar(): void;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm reading the code correctly, it seems like the case that distinguishes the two tryGetMemberInModuleExports* call-sites is a property named "default". Would it be interesting to test that explicitly.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Answered above.

Copy link
Copy Markdown
Member

@amcasey amcasey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems sensible but I don't understand clearly enough to "Approve".

Copy link
Copy Markdown
Member

@amcasey amcasey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying offline!

}
}

Debug.assert(name !== "default");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please add a comment explaining why this is true? Something like "default is a keyword and is not valid as an expression"?

@minestarks minestarks merged commit 8999411 into microsoft:master Jul 26, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants