tsd-lite should work alongside @ts-ignore and @ts-expect-error comments

[ekilah]

Hello! I'm a new user of this package via jest-runner-tsd. Enjoying it so far.

I ran into an issue today while implementing tsd-lite for the first time.

import {expectError} from 'tsd-lite'

type TSomeType = {foo: string}
declare const someObject: TSomeType

expectError(someObject.someMissingKey)

If I write the above code, things work great from tsd's perspective - the expectError line sees a type error, as expected.

However, my IDE (WebStorm) sees the error, too, and complains about it, which makes sense.

TS2339: Property 'someMissingKey' does not exist on type 'TSomeType'.

I'd like to avoid having these errors in my editor, which distract me from "real" errors in my project by cluttering my "project errors" console. So, I tried to use //@ts-ignore or the newer //@ts-expect-error feature:

With either flag, my editor is happy, but tsd-lite produces this error when I run the tests:

Expected an error, but found none.

Which kinda makes sense - I am suppressing the error, so I guess tsd-lite can't see it anymore? It'd be nice if this wasn't the case, but I'd understand if this is just a limitation of how the library works. I'm making this issue in hopes that there is a workaround possible here, or to at least document this for other users if not.

Note: I could make this issue over at tsd instead of here, if you think this is more of an upstream issue, but since I'm not using tsd directly, I started here.

---

I am configuring tsd-lite for the first time, so I wonder if this is partially related to my setup, so I'll quickly describe it here.

Basically I'm wondering if other users of this lib avoid including their test files in a tsconfig, which doesn't work well with my setup.

I've got multiple tsconfig files, one for my regular code and one for my tests. WebStorm doesn't to understand the file imports in my test files unless I have a tsconfig configuration that includes them, which is probably because of other settings I have in my tsconfig, like the paths setting to make an alias for relative imports with a ~. For example:

import {expectError} from 'tsd-lite'
import {ATypeOfMine} from '~/api/types' // '~' is resolved to `./src` via the `.tsconfig` `paths` key

I am not sure if my setup is part of the problem; I'm happy to take any advice on configuration if this problem doesn't occur for other folks.

[mrazauskas]

Thanks. This is very good question. Actually these are two problems in one – the test itself and IDE output.

---

First, I would advice to never use // @ts-ignore or // @ts-expect-error in your type test files (should add this to readme). Having a // @ts-* is silencing any syntactic and semantic errors which typescript would report. For example, here is my own mistake:

type M = expect.Matchers<void, unknown>;
type N = expect.Matchers<void>;
// @ts-expect-error
type E = expect.Matchers<>;

My hope was to test that at least one generic type argument is required, but I silenced syntax error instead. Ups.. Actually expectError must be improved. Currently there is no way to declare what error is expected or how many errors are expected?

This is address already. Here is a working example (already implemented!) from a work-in-progress type testing library:

test("required type arguments", () => {
  type M = Matchers<void, unknown>;
  type N = Matchers<void>;

  expect(() => {
    type E = Matchers;
  }).type.toThrow(
    "Generic type 'Matchers<R, T>' requires between 1 and 2 type arguments."
  );
});

---

As you noticed, altering code to please IDEs is not ideal. Would be better to instruct IDEs to treat these files as type tests, not as just another piece of TS code. Probably something like vscode-jest could be a solution. I don’t have an answer yet.

jest repo is good setup example. At the moment it has ca. 850 assertions in type test files (search for __typetests__ directories). Indeed all expectError asserts are red in IDE. Would be nice to improve this, or course.

[ekilah]

Glad to hear this isn't just me, and thanks for the thoughtful reply!

---

// @ts-ignore / // @ts-expect-error hide real, accidental errors too

Yeah, this is a fairly big annoyance with either flag, glad you pointed it out. I was thinking of a different kind of problem with them already: Say a future refactor to the code you are testing here, e.g. a change to rename TSomething or Matchers, might make your tests no longer test the correct failure, and you wouldn't get warned about it.

Your in-the-works library that would address this concern about "which error am I expecting here" sounds really neat! Can't wait to try it out.

I found myself wanting another thing it looks like you'll provide in that library if/when you release it, which is a way to use wrappers similar to jest's it/xit/skip/describe etc to organize and better label tests, while trying out tsd-lite via jest-runner-tsd. I might have to try out the other library a commenter added to that thread, too, though I haven't yet: https://github.com/TexKiller/jest-tsd-transform . Thanks for the link!

---

Telling IDEs to ignore these errors

I haven't had success finding a way to do that either, especially with my IDE of choice (JetBrains / WebStorm), but I will keep looking / my ears open too.

[mrazauskas]

Indeed it is very to have flags like skip, only. These are already implemented in the wip library. In general it works pretty well, I am just polishing edge cases like recursive types.

Regarding IDEs, my point is that here we need a dedicated extensions / plugins. The plan is to finish the library first and then I will try to address this as well. Never worked on an extension before. Curious to give it a try.

[mrazauskas]

TSTyche, the new testing tool which I promised, got published recently.

Repo: https://github.com/tstyche/tstyche
Documentation: https://tstyche.org

It has testing helpers like test() and describe(), run mode modifiers like .skip or .only and much more to offer.

---

tsd-lite is being sunset and will be eventually deprecated. #364

The feature you have requested will be added to TSTyche soon. I created an issue for tracking the progress: tstyche/tstyche#17