Double definitions not recognized

[andevsoftware]

TypeScript Version:

1.8.9

Code

import Item from "./Models/Item";
import ModelCollection from "ts-core/lib/Data/ModelCollection";

var modelCollection = new ModelCollection<Item>(Item, []);

Expected behavior:

Compilation without errors.

Actual behavior:

In order to replicate:

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

NOTE: I'm not sure if this is a TypeScript or Typings problem so I've also issued it here:
typings/typings#380

[mhegazy]

The first EventEmitter, referred to in the definition of Item is in exp-typings\typings\main\definitions\ts-data\index.d.ts line 109. The other EventEmitter used in Model comes from exp-typings\typings\main\definitions\ts-core\index.d.ts line 477.

the two classes seem identical, but they have a private member. from the compiler perspective these are different files.

Are the files ts-core\index.d.ts and ts-data\index.d.ts auto generated by typings?

[andevsoftware]

@mhegazy Thanks for your reply.

the definition files inside https://github.com/redound/ts-core/tree/dev-package/lib get generated after the tsc executes:
https://github.com/redound/ts-core/blob/dev-package/tsconfig.json

the definition files inside https://github.com/redound/ts-data/tree/dev-package/lib get generated after the tsc executes:
https://github.com/redound/ts-data/blob/dev-package/tsconfig.json

Typings then goes ahead and alters them resulting in the index.d.ts files inside the typings folder. I think the reason the EventEmitter referred to in the definition Item is caused by Typings actually including the definitions of ts-core also in the definition of ts-data itself. That's because ts-data has ts-core as a dependency. I believe I don't have any control whatsoever over the way typings does this. What do you think?

[mhegazy]

If there is a shared dependency, it should be factored out to a different component. ts-core-eventemitter. the other option, is make the contract of these declaration safe to use across different versions of your library, i.e. do not use private properties.

[unional]

How about protected properties? Should they be shared? Sounds like a touchy subject. 😏