Remove test import in README.md

[aryaemami59]

This PR:

• Resolves Add test() helper #63.

[mrazauskas]

Technically this is correct.

Did you notice that foo and bar are also not imported? Despite of that two assertions out of three are passing. They got type any. Simply imagine a situation where something anys because of refactoring code. expect-type is not able to catch such regression. (#64 is part of this problem.)

Another aspect: having Vitest import means that tsc will go on type checking Vitest types. Just put together a dummy repo with 2-3 test files and you will see the performance difference with import from Vitest and without. The difference is visible with naked eye. Having own test() helper would mean better performance for expect-type users.

[mrazauskas]

Another limitation of import {test} from 'vitest' is that test.only, test.skip and similar modifiers are defined on test(), but do not work as expected.

Recently I saw if() used as dummy test helper (that library is using tsd):

if ('when foo and bar are imported') {
  // make sure `foo` has type {a: number}
  expectTypeOf(foo).toMatchTypeOf<{a: number}>()

  // make sure `bar` is a function taking a string:
  expectTypeOf(bar).parameter(0).toBeString()
  expectTypeOf(bar).returns.not.toBeAny()
})

It has no .only or .skip and does not hurt performance.

[mmkal]

The scope of this library is test assertions, not to be a test runner. So no need to define a test export.

The example in question here is just that... an example. It's to give readers an idea of what they need to do to test their types. foo and bar being undefined doesn't seem important to me. Your point that two of the three assertions pass anyway because of any is separate, but worth considering. I've gone back and forth on whether expect-type should be strict about any even on the non-strict types like toMatchTypeOf. Currently the answer is no but maybe we should change that.

As for performance, test.skip etc. Those are reasonable points and I think a good enough reason to remove the test wrapper from the first example. Nobody should install vitest just for the sake of using expect-type. They can just write plain assertions. And of course installing a full-blown test runner slows down tsc (although you should try again with skipLibCheck - IMO that's always worth enabling).

Having said all that, if we remove the test wrapper from the first example, it might be nice to have a "Usage with test frameworks" section with some recommendations.

[mrazauskas]

Thanks for detailed explanation.

Within test frameworks section already exists at the bottom of the readme file. Extending it indeed sounds like a good idea.

[mrazauskas]

I've gone back and forth on whether expect-type should be strict about any even on the non-strict types like toMatchTypeOf. Currently the answer is no but maybe we should change that.

Sorry about making noise here. What about documenting the above? This would explain / resolve #55 and likely #64 as well.

But documenting this behaviour will conflict with other parts of documentation, like: "first-class support for: any (as well as unknown and never)". Hm.. I understood that anys are always explicitly handled, pointers to tsd issues made me think so.

Also "make sure" in the following is misguiding, because foo can be also any:

expect-type/README.md

Lines 15 to 16 in 9cda9e0

	// make sure `foo` has type {a: number}
	expectTypeOf(foo).toMatchTypeOf<{a: number}>()

[mmkal]

Yes, some clarification needed, how it was intended:

toEqualTypeOf: protects against any, lets you assert an exact type
toMatchTypeOf: ensure that a value matches a type, or since typescript uses structural typing, "has" a type. That's why any passes for toMatchTypeOf.

In practice, though, you're right that very few people will want an any except in a very small number of cases. And in those cases they could use toBeAny(). And now would be the time to make that change (pre-v1).

[mmkal]

Update: I thought a bit more, and I am struggling to think of any good/practical use for having assertions like expectTypeOf(foo).toMatchTypeOf<{a: 1}>() pass, when foo has type any. So, I opened #66 to make it so the only thing you can do with an any is expectTypeOf(foo).toBeAny().

FYI @mrazauskas

[mrazauskas]

As for performance, test.skip etc. Those are reasonable points and I think a good enough reason to remove the test wrapper from the first example. Nobody should install vitest just for the sake of using expect-type. They can just write plain assertions. And of course installing a full-blown test runner slows down tsc (although you should try again with skipLibCheck - IMO that's always worth enabling).

I used expect-type repo to make some performance tests with hyperfine. tsc was running using current tsconfig.json where only include was changed to: "include": ["test/types.test.ts", "test/usage.test.ts"] and "types": [] added.

With import {test} from 'vitest':

• 1056 ms (average of 10 runs, with 2 warm up runs)

Replacing the import with declare function test(name: string, fn: () => void): void;:

• 865 ms (average of 10 runs, with 2 warm up runs)

---

Yep, "skipLibCheck": true is set, but it does not help.

[aryaemami59]

@mmkal I removed the test import altogether.