hkt-toolbelt VS ts-patch

At the risk of too much self promotion, I have a much deeper and more feature complete treatment of many of these type-level computations, represented with higher minded types (which are thus composable) here:

https://hkt.code.lol/

This is my "lodash for types" project. It supports integer division for up to 2^64, for example. It has over 200 composable utility types.

yup, just found that, super neat, I am 100% interested in using this for other runtime validation...

It's interesting because I've always been under the impression the TS team was against the use of types at runtime (that's why projects like https://github.com/nonara/ts-patch) exist, but now they're doing it themselves with this project...

I recently learned about Typescript transformers[0] and wish they were better supported in a first-class manner. Working with ttypescript or ts-patch[1] is easy enough, but it still feels like you're doing something you shouldn't be doing.

My goal was to pass the Typescript types to the JS runtime, maybe there's a better way and GPT-4 just led me astray...

[0] https://github.com/itsdouges/typescript-transformer-handbook

[1] https://github.com/nonara/ts-patch

To accomplish this, I wrote a couple of transformer plugins for TypeScript. Now, tsc doesn't support plugins by default. (You may have seen plugins in the tsconfig.json for a project, but they are plugins for the editor's language server, not the compiler.) Luckily for us, again, there exists a fantastic open-source package to solve this problem. Ron S. maintains a package called ts-patch which, aptly, patches the tsc installation for a project to allow the project to specify compiler-plugins.