How to handle global type definition clashes

[Hotell]

TypeScript Version: 2.4.2

Let's say I'm using some unit/e2e libraries which are exposing same global functions, for instance test / describe but they have:

• 1st use case -> structurally similar types for both functions
• 2nd use case ( contrived one ) -> they have not structurally compatible definitions

-> I wanna got tsc run without errors for whole project ( source / unit tests / e2e files )

use case 1

let's say the test function has signature like this

libraryA:
type Test = (name: string, fn?: ProvidesCallback, timeout?: number) => void;

libraryB:
type Test = (name: string, fn: (t: TestController) => Promise<any>): this;

they have some discrepancies in other defintions but "skipLibCheck": true, comes here to save the day, which is not entirely ok. Why? well now, when I write test(...) I get test definition from libraryA instead of libraryB, which may break when one of those libs changes API, so it's a temporary OKish hack

use case 2

let's say they have different type defs for tests

libraryA:
type Test = (count: number, fn?: ProvidesCallback, timeout: number) => void;

libraryB:
type Test = (name: string, fn: (t: TestController) => Promise<any>): this;

now I'm screwed, because those 2 types are not structurally matching so I won't get tsc running without errors.

only solution for this use case, that comes on my mind, is to create base tsconfig.json, with only global types, that are not clashing and then creating extended tsconfig, which will override types appropriately and run them via -p configOne.json or just via CLI --types

This is currently a issue here:
AlexanderMoskovkin/testcafe-mocha-example#1
DevExpress/testcafe#1537 (comment)

I think either way this should be documented in Typescript docs if there are just solutions that I mentioned.

Thanks for any help !

[aluanhaddad]

While I generally come down pretty hard in favor of anything that would reduce declaration collisions and improve multi version scenarios, I think TypeScript's behavior is correct here.

Globals are bad design and nothing about testing frameworks makes them special or exempt from good practice.

I recommend https://github.com/substack/tape (and https://github.com/spion/blue-tape for asynchronous tests). Simple, concise, and good for the environment.

[mhegazy]

only solution for this use case, that comes on my mind, is to create base tsconfig.json, with only global types, that are not clashing and then creating extended tsconfig, which will override types appropriately and run them via -p configOne.json or just via CLI --types

that would be my recommendation here as well.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.