Comparison to dtslint

[eps1lon]

I'd like to know how your library compares to dtslint. As of right now it looks like I can achieve the same with dtslint's expect rule and tslint.

Do you have any issues with dtslint that you want to fix or features that you want to add?

[BendingBender]

From my experience with dtslint vs tsd:

• it's not possible to make an unnoticed typo in expectType<...>(...) (quite possible with dtslint: $ExectType, ...) to render the assertion meaningless
• the asserted types don't have to be absolutely identical to the types TS derives internally (in dtslint: string | number will pass, string|number not, string[] will pass, Array<string> not)
• each tested against type must have been exported, an assertion for a non-exported type won't pass, this way one can never forget to export a type
• checks for typings and files fields in package.json, points to broken settings/paths
• quite easy to set up, no config needed

[BendingBender]

This module is, however, quite young, it still misses a few features:

• no equivalent for $ExpectError
• tests for assignability, not type equality:

expectType<{[key: string]: any}>({foo: 'bar'}); // => OK
// while {[key: string]: any} is definitely not the same as {foo: 'bar'}
expectType<string | number>(1); // => OK

• not possible to tweak compiler options (strict would be very useful, see Make it strict by default and add ability to configure compilerOptions #13)
• is still a bit buggy ( Use types property, correctly test files for types in project sub-dirs #12)

[sindresorhus]

no equivalent for $ExpectError

I really wish we had this one.

not possible to tweak compiler options (strict would be very useful)

I assumed it was already strict. If not, we should definitely change the default to strict and add a way to opt-out.

[BendingBender]

I assumed it was already strict. If not, we should definitely change the default to strict and add a way to opt-out.

See: #13. :-)

It is not enabled by default, but we can discuss this issue there.

[blakeembrey]

@sindresorhus I was thinking about $ExpectError and I think you can do it using conditional types and extracting the types you wish to validate. Here's an example:

export type TypeOf<T, U> = Exclude<U, T> extends never ? true : false;

export function test(_: string): void {}

expectType<TypeOf<[string], Parameters<typeof test>>>(true);
expectType<TypeOf<[number], Parameters<typeof test>>>(false);

[SamVerschueren]

expectError is now also part of the API

expectError<string>(5);
//=> Passes

expectError<string>('🦄');
//=> Expected an error, but found none.

expectError(foo(1, 2));
//=> Passes if `foo` only accepts strings as argument types

[SamVerschueren]

Are there any other things that don't work for you? Please feel free to let me know so I (or we) can fix this.

@BendingBender What do you exactly mean with:

expectType<{[key: string]: any}>({foo: 'bar'}); // => OK
// while {[key: string]: any} is definitely not the same as {foo: 'bar'}

Why aren't these the same? foo is a key of type string and any matches everything, so also the string bar. I probably don't see the issue so feel free to elaborate :).

[eps1lon]

Are there any other things that don't work for you?

I'm missing some context why we need this package. Does your expectError API provide some additional functionality compared to $ExpectError? Same for expectType.

[SamVerschueren]

It certainly does, just read this issue microsoft/dtslint#191

// dtslint
const o = from([of(1), ['test'], iterable]); // $ExpectType Observable<IterableIterator<number> | Observable<number> | string[]>

// tsd-check
expectType<Observable<IterableIterator<number> | Observable<number> | string[]>>(from([of(1), ['test'], iterable]));

Already explained by @BendingBender, you can't make typo's because the TypeScript compiler will tell you it's wrong. dtslint uses comments, how many typo's do people make when writing those comments? Especially with those complex types.

Secondly, tsd-check uses the REAL types. What I mean is, if I expect an RxJS observable, but the function is returning a Zen-observable, tsd-check will catch this, I don't think dtslint does because it uses string matching and for them, 'Observable' === 'Observable'.

And thirdly, one I find quite nice to have, is that when writing tests, the TS compiler already gives you feedback if you do something wrong.

expectType<string>(1);

This will already be marked with a red line by your text editor because the compiler detects a type mismatch. This is not the case with dtslint either.

So yes, in my opinion, this library has benefits over dtslint. But maybe I'm biased as I'm the author ;).

[eps1lon]

Just to be clear I didn't mean to attack you. I think all of those points are perfectly valid. I just think it's very important to list related work in packages and how it compares. Otherwise the choice for or against a package becomes arbitrary.

[SamVerschueren]

Do you think it would help if we documented in the readme?

[SamVerschueren]

If we document this, I don't want it to become oh look, ours is much better because this and this reason. Not sure how to do it decently without attacking anyone's work.

[BendingBender]

@SamVerschueren

Why aren't these the same? foo is a key of type string and any matches everything, so also the string bar. I probably don't see the issue so feel free to elaborate :).

What I mean is that the type {[key: string]: any} will accept pretty much any object and thus the whole assertion is rendered useless. This is an extreme case, in reality it can be much more subtle:

const foo = () => 'foo';

expectType<string | undefined>(foo());

This will pass. The problem is that actually I wanted to assert that foo returns a string | undefined and my expectation was that this check should fail. But string is assignable to string | undefined and thus this passes. This is what I mean when I say that this is not actually a type comparison but an assignability check.

[mike-north]

I'm looking to try this library out, and can't figure out if there's good support for the "sufficiently narrow" test cases I typically write when working with dtslint.

I usually rely on this aspect of dtslint that @BendingBender pointed out out

[in tsd-check] the asserted types don't have to be absolutely identical to the types TS derives internally (in dtslint: string | number will pass, string|number not, string[] will pass, Array not)

i.e., if I have a function foo() that returns a Promise<[number, number]> I could write

foo(); // $ExpectType Promise<[number, number]>

and I'd be good to go, since I'm asserting against the stringified type return value of foo().

In this library I could do

expectType<Promise<[number, number]>>(foo());

But it also would pass if I introduced a bug causing foo to return a wider type, since structural type equivalence is the means of assertion, as opposed to exact match of stringified types

As a result, the following (potentially undesirable) changes to foo would also pass the assertion above

function foo(): Promise<[number, any]>; 
function foo(): Promise<[any, any]>;
function foo(): Promise<any>;
function foo(): any;  

Are there plans to handle any cases like these? Do consumers of this library typically just worry about testing that types are sufficiently wide and don't care as much about them being sufficiently narrow?