Double definitions not recognized

[andevsoftware]

I see some unexpected behaviour having several definitions that appear in multiple packages that have the same dependencies. I reach out because I'm not sure if it's me misusing it or typings needing improvement.

To test this:

clone https://github.com/redound/exp-typings.git
cd exp-typings
typings install
tsc

Then you get the above error indicating that EventEmitter and EventEmitter are incompatible. (It's the same EventEmitter).

[unional]

It's fixed in latest release

[andevsoftware]

@unional I think it's a separate issue, I've updated to that update before I issued this.

[unional]

Yup. Just realized that.

[andevsoftware]

@unional Any idea what the problem might is?

[unional]

Need the master to handle this.
I can see what's the issue, but...

As said in the error, the protected field is what caused the incompatibility. (private fields too).

If I remove protected _eventCallbacks: any; from EventEmitter and private _params from Event<T>, it build successfully.

Private properties shouldn't be included in declaration, for sure.

I'm not sure about protected properties. Likely this involves TypeScript team.

@blakeembrey thoughts?

[blakeembrey]

I'll look through existing TypeScript issues to understand the reasoning here from TypeScript's team, but it's pretty simple to verify in a standalone test:

export class Test {
  private method () {}
}

export class Test2 {
  private method () {}
}

export function compare (t: Test) {}

compare(new Test2())

index.ts(11,9): error TS2345: Argument of type 'Test2' is not assignable to parameter of type 'Test'.
  Types have separate declarations of a private property 'method'.

[blakeembrey]

Seems like microsoft/TypeScript#6496 and microsoft/TypeScript#6365 are relevant here. I can't tell the real reasoning right now why private and protected changes it from a structural to a nominal type check, it seems to me they should all be structural and private or protected shouldn't even be considered in assignability because they can't be accessed outside of the class.

[andevsoftware]

@blakeembrey Thanks clearing that up. What would you recommend for now so that the Item satisfies the Model? I've made the property protected which causes the same error. The only route is to make it public i guess?

[blakeembrey]

From the spec: https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#3112-type-and-member-identity. You can create an interface inline that describes what the value should conform to instead of using the class type. E.g. function accepted (e: { on (type: string, fn: (...args: any[]) => any)): any }). That'll make the check properly structural instead of based on identity until such a time that Typings can optimize the compilation output to avoid duplicates like this (or TypeScript 2.0).

[blakeembrey]

I'm going to open an issue to see if I can understand more, at the very least it'll be closed as a duplicate but it'll alert them that it's maybe an issue.

[blakeembrey]

Ah, I see you already created microsoft/TypeScript#7743 too. I guess we'll see what gets said anyway.

[andevsoftware]

@blakeembrey Yes, we'll see.

[blakeembrey]

Ok, looks like making an abstract interface may be the best way for now until Typings/TypeScript can handle de-duping better.

[blakeembrey]

Closing as answered for now.