chore(dtslint): mention TSTyche in the readme

[mrazauskas]

Would it be possible to add TSTyche in the list of recommended type testing tools?

---

I have build TSTyche, because it was not possible to find a tool which could make it a breeze testing types in a large monorepo with around 1500 assertions. Without a dedicated CLI tool and support for helpers like test() or describe() that was a pain.

TSTyche implements the test helpers with .only and .skip run mode modifiers, expect style assertions and has a mighty test runner. For example, it can select test files by path, filter tests by name and pass them through TypeScript 4.8 and latest:

tstyche JsonObject --only external --target 4.8,latest

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

---

I am biased, but it seems like TSTyche is the most capable type testing tool around. Currently it is in rc and a stable version will be released in few days.

[jakebailey]

I don't mind mentioning more tools, though at that point we should probably also mention vitest's type testing (which looks very similar?)

[mrazauskas]

Thanks for quick response.

I was thinking abut making the list longer. There is also @arktype/attest or @glint/type-test (exotic syntax). The latter wraps around expect-type, just like @japa/expect-type.

Vitest is also using expect-type. They simply spawn a process, run tsc and process the result. It sounded like maintainers are not sure about this approach anymore and are looking for alternatives. Indeed there are some limitations (e.g. no support for references).

Given all this context, it sounded like the best idea would be to open a PR adding only my tool. Others can do the same if they are interested. Or someone could create a more complete list later.

[mrazauskas]

Just to add, TSTyche is written from scratch. I was helping with jest-runner-tsd (another testing tool) and could see the problems from inside.

It was obvious that integration with JavaScript testing tool is not the best solution. For instance, Jest or Vitest do not know how to install different versions of TypeScript package. Why they should know? Standalone type testing tool was obviously better solution.

Differently from similar tools, TSTyche is wrapping around TypeScript's ProjectService. @jakebailey I have to say: thanks a lot for this idea! (I picked it up from here: typescript-eslint/typescript-eslint#6575). That was a significant performance boost.

TSTyche compares types programatically, hence typescript have to be patched (not elegant, but I don’t see it as problem). Instead of publishing patched TypeScript package (like tsd does), TSTyche is applying the patch in memory. This makes it possible to use TypeScript builds from every-ts (the bisect command also works).

These all are niche problems, of course. Just trying to illustrate why I think that TSTyche is the most capable type testing tool around. The familiar testing APIs makes easy to start using it. If every-ts bisect is needed at some point, this will also work.

---

Sorry, I have no idea what changesets are. Hope that is not an issue.

[jakebailey]

TSTyche compares types programatically, hence typescript have to be patched (not elegant, but I don’t see it as problem)

This is getting off topic, but I'm curious what you need to patch in; isTypeAssignableTo is now documented on the checker (but has been available for a long time), and I would expect to cover a lot of what you may need.

[jakebailey]

Sorry, I have no idea what changesets are. Hope that is not an issue.

The CI will require one, but since this is just a readme change, you may just be able to do pnpm changeset --empty.

[mrazauskas]

This is getting off topic, but I'm curious what you need to patch in

Currently I have to expose isTypeIdenticalTo(), isTypeSubtypeOf() and also isTypeStrictSubtypeOf(). (Actually it could be better to use isTypeRelatedTo() directly.) Also it might be I will need instantiateSignatureInContextOf() in near future.

What TSTyche is doing is not patching in the strict sense. I understand this more like extracting parts of TypeScript's code and wrapping a type test runner around them. One can see TSTyche as a per-file type checker with benefits (assertions, different TS versions, etc). In a way it could also reimplement TypeScript's code to do its job. Only that this is unnecessary duplication.

For example, Yarn or Volar are patching TypeScript. They want to run the same tsc command, but it must act differently than originally intended. In contrary, TSTyche wants TypeScript to act exactly as it was intended (otherwise testing on different versions makes no sense).