Run dedicated typescript types tests using tsd

[jankapunkt]

Summary

Due to multiple conflicts with the type signatures in our Request object, I started a little spec for types testing using tsd.
Please note, that I added dev dependencies (express, undici) for now. I am currently unsure if this is good in the long-run and we may rather extract these into the specific repos for express, koa etc.

Linked issue(s)

#356 #362

Involved parts of the project

dev-only, tests, typescript

Added tests?

yes

OAuth2 standard

not involved here

Reproduction

• checkout branch
• npm install
• npm run test:types

[mrazauskas]

@jankapunkt Can I ask why did you pick tsd? Did you consider any alternatives? For instance, did you try TSTyche (https://tstyche.org)? I am its author, so that is why your PR made me curious.

Only my opinions, here is how TSTyche could be helpful for your project:

• has describe() and it() helpers (just like in your unit tests) with .skip and .omit
• the install size is only 260kB (instead of 39MB)
• uses already installed typescript package instead of shipping a patched copy
• even better, can test agains a range of TypeScript versions (tstyche --target '>=5.4') or any specific version (i.e. does not require the typescript package to be installed at all)

Might be you have your own arguments and the decision is made already. If so, sorry about the noise.

[jankapunkt]

@mrazauskas thank you for the input. I chose tsd mostly because the famous unicorn guy with the puppy dog is working on it, haha. Addtionally I like the ease of use and convention over configuration. I also looked at your repo and it looks future proof.
I will check if it will also work the same frictionless as tsd and then decide what to use in the end.

Maybe @shrihari-prakash or @dhensby have also an opinion on this one

[mrazauskas]

Hm.. extends must be a sibling of compilerOptions. It is not a compiler option. Really strange tsd does not complain about that.

[mrazauskas]

the ease of use and convention over configuration

Indeed that is good. There are also other nice aspects of tsd, like comparing types programatically. But there are the odd sides too. For instance, if you would add some utils.test-d.ts file, it would not be picked up (only index.test-d.ts is checked). And there is no simple way to see which files the CLI does actually select for the run.

In contrary, TSTyche would select all **/*.tst.* files and would list them while running the tests. Just like any JavaScript test runner does. (And more: it would show which TypeScript version and TSConfig file were used for the run.)

I do like many aspects of tsd, but also there are many oddities that made me think I could build something better. That’s why I suggested trying out TSTyche.

(Why didn’t I try to improve tsd? I did, actually. But if you look at the repo, nobody is responding to the issues or reviewing non-essential PRs anymore. Seems like the last bug fix was merged in March 2023.)