toBeBoolean behaves differently from toEqualTypeOf<boolean>

[boris-petrov]

Playground link.

import { expectTypeOf } from 'expect-type';

let x!: any;
expectTypeOf(x).toBeBoolean();
expectTypeOf(x).toEqualTypeOf<boolean>();

The first expectTypeOf passes (which it should not) but the second errs (correctly). They should both err.

P.S. The same is true for other such helpers (like toBeArray, etc).

[mmkal]

Yes, I agree, this should really be a toEqualTypeOf rather than a toMatchTypeOf. It'd be a "breaking" change, but would probably only break anys that have crept into people's code, so that's probably a good thing (plus this library is still technically v0).

[mmkal]

Note: some nuance here. I think this applies to primitive, but I don't think it makes sense for toBeFunction, toBeArray and toBeObject to use strict equality for now. It might make sense if helpers like toBeAFunction, toBeAnArray and toBeAnObject were added - but I would rather optimise for what I suspect is the most common/intuitive usage. Anyone who wants something else can pretty easily use toEqualTypeOf or toMatchTypeOf if necessary.

The primitive case will be fixed in #16.

[mmkal]

Copy-pasted from docs added in #16, this will be the new behaviour:

---

.toBe... methods allow for types which extend the expected type:

expectTypeOf<number>().toBeNumber()
expectTypeOf<1>().toBeNumber()

expectTypeOf<any[]>().toBeArray()
expectTypeOf<number[]>().toBeArray()

expectTypeOf<string>().toBeString()
expectTypeOf<'foo'>().toBeString()

expectTypeOf<boolean>().toBeBoolean()
expectTypeOf<true>().toBeBoolean()

.toBe... methods protect against any:

const goodIntParser = (s: string) => Number.parseInt(s, 10)
const badIntParser = (s: string) => JSON.parse(s) // uh-oh - works at runtime if the input is a number, but return 'any'

expectTypeOf(goodIntParser).returns.toBeNumber()
// @ts-expect-error - if you write a test like this, `.toBeNumber()` will let you know your implementation returns `any`.
expectTypeOf(badIntParser).returns.toBeNumber()

---

Note that this is different from .toEqualTypeOf<boolean>() - because expectTypeOf<true>().toEqualTypeOf<boolean>() would fail whereas expectTypeOf<true>().toBeBoolean() passes - but that's correct behaviour IMO. Let me know if you disagree.