test(types): introduce tstyche instead of tsd

[avallete]

What kind of change does this PR introduce?

Following up: #632 (comment)

• Introduce tstyche to improve the type testing by adding expected message matching to the @ts-expect-errors
• Leverage tstyche to check that types tests passes across a wide ranges of Typescript versions (>=4.7)
• Remove tsd since we no longer needs it. Remove ts-expect and extract TypeEqual which is the only used utils from it.

[mrazauskas]

Thanks for giving TSTyche a try. Glad to see this. I have left few inline comments.

One more important detail. By default, TSTyche logs the installed typescript package. The version used for testing is printed in the log:

This is different from tsd which ships with its own copy of @tsd/typescript. The exact version can be found here:

postgrest-js/package-lock.json

Lines 1123 to 1124 in 823f28f

	"node_modules/@tsd/typescript": {
	"version": "5.4.5",

---

All depends on your strategy. You can run npx tstyche --target 5.4 to test against TypeScript 5.4.5. (Few checks error messages are failing because of minor changes between TypeScript versions.)

Or you can run npx tstyche --target '>=5.4' to test against TypeScript 5.4, 5.6, 5.7, etc. (Takes time. Might be too much for local checks. But definitely good idea for CI.)

[avallete]

Thanks for giving TSTyche a try. Glad to see this. I have left few inline comments.

One more important detail. By default, TSTyche logs the installed typescript package. The version used for testing is printed in the log:

This is different from `tsd` which ships with its own copy of `@tsd/typescript`. The exact version can be found here:

postgrest-js/package-lock.json

Lines 1123 to 1124 in 823f28f

	"node_modules/@tsd/typescript": {
	"version": "5.4.5",

All depends on your strategy. You can run npx tstyche --target 5.4 to test against TypeScript 5.4.5. (Few checks error messages are failing because of minor changes between TypeScript versions.)

Or you can run npx tstyche --target '>=5.4' to test against TypeScript 5.4, 5.6, 5.7, etc. (Takes time. Might be too much for local checks. But definitely good idea for CI.)

That's great ! Definitely something we want in CI/CD ! We had issues before with having breaking changes between versions of typescript on the user project, so if we can cover that easily, that's perfect !

I would say maybe cover all above or equal to the version of typescript we do use in supabase-js repo ? https://github.com/supabase/supabase-js/blob/7876a2487d8db598a306eb0baa9a5f1d926b06d5/package.json#L79

So tstyche --target '>=4.5'.

[mrazauskas]

So tstyche --target '>=4.5'.

Only >=4.7 is supported. Sorry... But if you run npx tsc --version here or in supabase-js repo, they both are currently using TypeScript 4.7.4. So, perhaps tstyche --target '>=4.7' is fine?

---

• TypeScript 4.7 was released 3 years ago (source)
• DefinitelyTyped tests types agains versions of TypeScript that are less than 2 years old (source)

That’s why I was thinking that keeping support only for >=4.7 is fine. Also TypeScript 4.7 was the first one with modernised module resolution (node16). This means compiler options got modernised and testing older versions got more complicated, because the new options are causing errors.

[avallete]

So tstyche --target '>=4.5'.

Only >=4.7 is supported. Sorry... But if you run npx tsc --version here or in supabase-js repo, they both are currently using TypeScript 4.7.4. So, perhaps tstyche --target '>=4.7' is fine?

• TypeScript 4.7 was released 3 years ago (source)
• DefinitelyTyped tests types agains versions of TypeScript that are less than 2 years old (source)

That’s why I was thinking that keeping support only for >=4.7 is fine. Also TypeScript 4.7 was the first one with modernised module resolution (node16). This means compiler options got modernised and testing older versions got more complicated, because the new options are causing errors.

Still worth mentioning that re-writing the types, we did had some frictions using some non 4.5 compatibles typing logic: #571

But as time pass, I guess we can expect people to migrate more and more and this retro-compatiblity to be less and less useful.

[avallete]

Asking review from @soedirgo for approval

[github-actions]

🎉 This PR is included in version 1.21.4 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀