Typescript gets confused with a variable and an imported interface with the same name

[louy]

TypeScript Version:
1.8.0-1.8.7

Code

import {Key} from 'types'; // Key is an interface
const Key = { test() {} };
Key.test();
export default Key;

Expected behavior:

Key.test();
exports.default = Key;

Actual behavior:

types_1.Key.test();
exports.default = types_1.Key;

[RyanCavanaugh]

We should be issuing a Duplicate Identifier error on Key since we otherwise couldn't emit this correctly in transpile scenarios

[louy]

Key is an interface though. It doesn't have any value. It shouldn't be a duplicate identifier.

[RyanCavanaugh]

The problem is that when a file gets compiled through ts.transpile, we don't do any module lookup, symbol resolution, etc, so we have no way of knowing that that is the case.

[louy]

I don't see why this should be fine...

interface Key {}
const Key = {};
export default Key;

...and this should not:

interface.ts

export interface Key {}

key.ts

import {Key} from './interface';
const Key = {};
export default Key;

[louy]

I see your point...

[louy]

how about this:

when #transpile sees two duplicate identifiers, it checks if the local definition has a value. if it does (i.e. the local definition is not an interface/type) #transpile uses it. if it doesn't have a value, #transpile uses the imported one.

[RyanCavanaugh]

when #transpile sees two duplicate identifiers, it checks if the local definition has a value.

The meanings of a local declaration could be still sourced in another file. Consider

a1.d.ts

namespace X {
  export interface Y { }
}

a2.d.ts

namespace X {
  export var Y;
}

foo.ts

// might be referencing a1 *or* a2, we can't tell
import Key = X.Y;

[louy]

in that case both namespaces have the same name X. we don't have a2_1.X. as there's no import ... from.

[louy]

And you can't have duplicate namespaces I believe.

/// <reference path="a2" />
import {X} from 'a1';

shouldn't work.