feat: add typeof assertion

[Shinigami92]

This adds a new assertion that replaces expect(typeof actual).toBe('string') with expect(actual).toBeTypeOf('string')

Please let me know where I need to add docs and/or tests, I'm very unfamiliar with the structure of the repo 😅

Edit:
Somehow there is a chai typeOf https://www.chaijs.com/api/assert/#method_typeof
But not sure how or if this is in any way accessible from vitest

[netlify]

✔️ Deploy Preview for vitest-dev ready!

🔨 Explore the source changes: f6a09f1

🔍 Inspect the deploy log: https://app.netlify.com/sites/vitest-dev/deploys/620c0c5ce4c3060008576559

😎 Browse the preview: https://deploy-preview-762--vitest-dev.netlify.app

[sheremet-va]

You would need to add docs to api/index.md i think
And test should be somewere in the test/core/test 👀

[sheremet-va]

Somehow there is a chai typeOf https://www.chaijs.com/api/assert/#method_typeof

I think it is accesible with:

import { assert } from 'chai'
assert.typeOf()

[Shinigami92]

I think it is accesible with:

import { assert } from 'chai'
assert.typeOf()

Tested this, but it's not so accurate and the negation with .not.toBeTypeOf shows the wrong message.
So I will leave it as I implemented it 🙂

[Shinigami92]

@sheremet-va Ready for a second review 🚀
Thanks for your review

[sheremet-va]

LGTM
Thank you for PR!

[patak-dev]

Nice! About the name, shouldn't it be toBeOfType instead of toBeTypeOf

expect(actual).toBeOfType('string')

because it is

typeof actual === 'string'

So, the type of actual is string
And we want to say now that we expect actual to be of type string

It is different than for toBeInstanceOf, as with it the construct is actual instanceof expected. So the API for it in Jest sounds right.

[Shinigami92]

Nice! About the name, shouldn't it be toBeOfType instead of toBeTypeOf

expect(actual).toBeOfType('string')

because it is

typeof actual === 'string'

So, the type of actual is string And we want to say now that we expect actual to be of type string

It is different than for toBeInstanceOf, as with it the construct is actual instanceof expected. So the API for it in Jest sounds right.

Yes and no, cause there is the real typeof actual === 'string', it's named after this typeof where folks are familiar with

[patak-dev]

I think that every other API in expect reads well. IMO, even if some users may initially reach out toBeTypeOf('string'), the correct naming here is toBeOfType('string') and with TS and autocomplete people shouldn't have issues finding/using it. @sheremet-va ?

[Shinigami92]

I think that every other API in expect reads well. IMO, even if some users may initially reach out toBeTypeOf('string'), the correct naming here is toBeOfType('string') and with TS and autocomplete people shouldn't have issues finding/using it. @sheremet-va ?

Would you be at least satisfied with an alias?
I also already thought about aliases like typeOf and notTypeOf and such.
Like currently you can use e.g. expect(...).toMatch() or expect(...).match()

[patak-dev]

For reference, regarding the naming in chai, there it is

assert.typeOf('tea', 'string', 'we have a string');

but that reads well: type of 'tea' is 'string'

[sheremet-va]

I think that every other API in expect reads well. IMO, even if some users may initially reach out toBeTypeOf('string'), the correct naming here is toBeOfType('string') and with TS and autocomplete people shouldn't have issues finding/using it. @sheremet-va ?

I like the current version because it is consistent with toBeInstanceOf

[patak-dev]

I like the current version because it is consistent with toBeInctanceOf

But it isnt consistent to me 🤔
It is different than for toBeInstanceOf, as with it the construct is actual instanceof expected. So the API for it in Jest sounds right.

typeof actual === expected
actual instanceof expected

the of refers to actual in the first, and to expected in the second

Grammarly complains for "Expect something to be type of string". And the casing, TypeOf instead of typeof also affects here.

Imagine that instanceof was called classof and used in JS as classof actual === expected. Should the method be called expect(actual).toBeClassOf(expected) then? Here it is easier to see why that wouldnt work and the method should be toBeOfClass or toBeInstanceOf

[Aslemammad]

toBeTypeOf is more accessible, but toBeOfType suits well here, and I guess it can be easily found with TS! so no problem on that side, and even if some users have trouble with that naming, we can mention it in the docs why we prefer toBeOfType!

[antfu]

I'd vote for toBeTypeOf as it matches the wording order of the keyword typeof, which to me will be more intuitive and easier to find.