Exported variable X has or is using name 'Account' from external module Y but cannot be named

[robyoder]

TypeScript Version: 2.7.0-dev.20180120

Search Terms: "named", "account", basically the title of this issue

Code

//// tsconfig.json
{
	"compilerOptions": {
		"declaration": true
	}
}

//// index.ts
import * as model from "./model";
export const func = (user: model.User, account: model.Account, foo: model.Foo) => {};

//// model/index.ts
export * from "./account";
export * from "./foo";
export * from "./user";

//// model/account.ts
export interface Account {}

//// model/foo.ts
export interface Foo {}

//// model/user.ts
export interface User {}

Expected behavior:

This would compile.

Actual behavior:

src/index.ts(4,14): error TS4023: Exported variable 'func' has or is using name 'Account' from external module "/Users/rob/Projects/named/src/model/account" but cannot be named.

Additional information:

This only fails when the interface is named "Account". If I rename it to "Account2" or anything else, it works fine. That was the purpose of including the "User" and "Foo" types here. Those can be removed and it still fails. This seems so bizarre, but I've reproduced it in a brand new repository, so it seems real.

Again, if I import directly from the file it works fine, but the other two types work fine without that:

import * as __Account from "./model/account";

I was so excited to get my hands on the RC and start removing all these extra imports, and that's how I hit this because we have a class named Account and the problem was not fixed for it (see related issues).

Playground Link:

I wasn't sure how or if I could recreate this in the playground. Seems limited.

Related Issues:

This is the exact same as my previous issue, #20657, except that it now fails only for the word Account (as far as I've found). @weswigham fixed that one in #20661, and nothing looked out of the ordinary.

So this is related to the same issues that that issue is related to: #5938, #8612, #19825

There is still another open issue with the same error message: #9944. I'm unclear what the difference is on that one, but it's pretty old. Seems to be maybe more about inferred types? Here we are only dealing with explicit types.

[weswigham]

So, get this. There's a global-scoped interface named Account in lib.d.ts (learned that today), which the module-level declaration hides, which causes us to ensure that the name is qualified correctly and refers to the correct interface. As it turns out, our logic for determining if that qualification is valid is inaccurate in the presence of export * from "..." declarations, since those cause the exports of one symbol to merge up into the exports of another, without making the module symbol in question directly accessible. And that is why it only happened if the interface was named Account.

[weswigham]

Fix is up 😉

[robyoder]

Brilliant. Now that you mentioned that, I think I've had trouble with that global Account before. Like I used the Account interface without importing it and got errors in all the wrong places. 😛

Thanks! ❤️