Type fixes & acceptance tests

[mike-north]

• Fixes type compile errors introduced by Allow generic types for IConnectionObject #22
• Type-safety around "promisified" methods object, invoked through postMessage channel (see included tests that demonstrate this)
• Type information is now tested via dtslint, w/ acceptance tests based around README examples

[ahtcx]

What compile errors were you getting?

[Aaronius]

Thanks @mike-north, especially for hooking up tests. @paulblyth If you ever have a moment I'd like to get your review on this as well.

[mike-north]

What compile errors were you getting?

you had

penpal/src/index.d.ts

Lines 12 to 14 in 8c7d9f0

	type ConnectionMethods<T> = {
	[P in keyof T]: () => Promise<any>;
	};

and are using it in several places without providing a generic argument

penpal/src/index.d.ts

Line 3 in 8c7d9f0

interface IConnectionObject<Methods extends ConnectionMethods> {

penpal/src/index.d.ts

Line 8 in 8c7d9f0

interface IChildConnectionObject<Methods extends ConnectionMethods> extends IConnectionObject<Methods> {

(and more)

Additionally, the types around parent/child connection methods weren't offering any type safety, or properly taking into account that

{
   add(number, number): number
}

turns into

{
   add(number, number): Promise<number>
}

[mike-north]

Remaining test failures are likely due to forks not having access to your sauce labs credentials (in travis, forks have no environment variables for security reasons). You could probably just open a different PR on a branch in this repo and close this one

[mike-north]

This is the new default type parameter that fixes the compile errors. {} is effectively any non-null, non-undefined value. object may be a more reasonable default, but it would potentially break some consumers and necessitate a major release

[ahtcx]

My bad... Nice PR though!

[Aaronius]

In the file that gets emitted as lib/index.d.ts, my IDE (Webstorm) is flagging this line:

Promise: typeof Promise;

It says: TS2693: 'Promise' only refers to a type, but is being used as a value here. Is this a cause for concern?

[Aaronius]

Oddly, I don't get that flag in types/index.d.ts. I might need to research this one.

[Aaronius]

Ah, it's because tsconfig.json isn't in lib. This doesn't concern me.

[mike-north]

Ah, it's because tsconfig.json isn't in lib. This doesn't concern me.

typically I like to keep the tsconfig.json in a subfolder unless type-checking or TS compilation is necessary for building the library. Even in that case, it's usually desirable to have a different config for declarations.

[Aaronius]

Published in 3.0.5.

[Aaronius]

Thanks again for putting the work into this.