Asserting against type parameters (possible with dtslint)

[leighman]

We have a function

export const createTableInterface = <
  A extends string = never,
  U extends TableDetails<A> = never
>() => <K extends keyof U>(table: K) => (
  pg: PgQueryInterface,
): TableInterface<A, U, K> => {

which should be used like
createTableInterface<keyof Tables, Tables>()
where Tables is some generated type.

Slightly hacky but I think the only way to allow the user to provide the Tables interface that conforms to a particular shape.

With dtslint we could write tests like

createTableInterface<number>() // $ExpectError
createTableInterface<string, Tables>() // $ExpectError

which assert/document the behaviour of the type parameters are correct.

Tests like this don't seem to be possible with tsd. Is it something that could be supported? Are they just bad tests?

Thanks.

[sindresorhus]

Have you tried expectError(createTypedPgHelper<number>())?

[leighman]

That fails with Type number does not satisfy the constraint string which is true but I also want to document and to assert that the constraint remains in place in the future.

[SamVerschueren]

You are right, it should work. We have a predefined list of errors that are catched by expectError. It's hard to know all use cases beforehand as we don't want expectError() to swallow syntactical errors for instance.

I've added the diagnostics code to the list of errors that should be swallowed by expectError. When I make a new release, it should be possible to use it like @sindresorhus suggested.

expectError(createTypedPgHelper<number>())

[SamVerschueren]

Released as 0.13.1