Following documentation, regarding a tip about `@ts-expect-error`, I cannot make tests behave as I would expect from the documentation about vitest HOT 5 OPEN

It might be that "tip" is outdated or simply wrong. Currently, vitest --typecheck cannot test single test file in both mode and prioritized typecheck mode. See also:

• #5019 (comment)

I'm not sure what's the best way to do this currently other than running vitest twice.

from vitest.

I'm not sure what's the best way to do this currently other than running vitest twice.

Note that // @ts-expect-error can hide typos in type names as well. Those are stripped entirely. Nor executing the test files, neither running vitest twelve times can help.

Solution: the old good Separation of Concerns principle. Use JavaScript testing tool to test runtime behaviour. Use specialised type testing tool to test types. There are at least two type testing tools which offer a type error assertion instead of // @ts-expect-error. The comment belongs to compiler, it is not meant for testing types.

from vitest.

@mrazauskas

There are at least two type testing tools which offer a type error assertion instead of // @ts-expect-error.

Could you please refer to these tools for clarity?

With Vitest, I gravitated towards @ts-expect-error as the most readable solution, and I will probably keep using it despite the possible issues highlighted, unless said tools are better, because the alternative was rather messy.

A minimal example of my use case, for context:

// to test against
function argFail<const T extends [1, never, 3]>(...arg: T) {}

//#region readable
argFail(
    1,
    // @ts-expect-error invalid
    2,
    3,
);
//#endregion

//#region messy, but intended way of testing, with expect-type?
type argFail_params = Parameters<typeof argFail>;
const arg = [1, 2, 3] as const;
expectTypeOf(arg[1]).not.toMatchTypeOf<argFail_params[1]>();
//#endregion

In a realistic scenario, argFail's arg: T parameter might also become too complex to properly extract it and make it testable without going somewhat mad.

Much more practical to just test a natural invocation of argFail with a not-quite-intended @ts-expect-error, that is resilient to refactors, than to bring in what I would consider a brittle and indirect way of expressing what I want to test.

from vitest.

Could you please refer to these tools for clarity?

Sure. I had in mind:

• tsd (not recommended: still maintained, but it did not receive any significant improvement for very long time);
• and tstyche (my own project: does more than tsd could and I work on more features).

To be honest, a type error assertion is not an ideal solution too. It would be the best to have .not.toBeCallableWith() matcher. As you know, expect-type has .toBeCallableWith(), but it does not work with function overloads and generic functions. They do not implement .not.toBeCallableWith() at all, but suggest to use // @ts-expect-error.

This matcher is complex. The most interesting part is to resolve argument types of generic functions. Programatically this is possible and I have a working prototype. That means that eventually tstyche will have .not.toBeCallableWith() with support for overloaded and generic functions.

from vitest.

Cheers, as I suspected there's not really a canonical way to go about this, and so I will stick to @ts-expect-error.

I will leave it to the maintainers to decide about the tip in the docs, but if I may provide input, it did waste me some time to realize that it's not working as intended, and at least some warning around it would be a welcome addition while the upstream issues are resolved.

from vitest.