typescript-runtime-type-benchmarks
typescript-runtime-type-benchmarks copied to clipboard
Discussion about codegen class of libraries
The ts-auto-guard package (#1319) has a codegen approach.
I would like to know if this fits within the thesis of this repo.
The original idea was to have code-first libraries.
But I can definitely see the argument for TypeScript types being also code first. I don't have a strong opinion one way or the other, and would love to hear more community feedback on this one.
My questions are, and feel free to add your own too for consideration:
- Should these packages be allowed?
- If so, should there be a separate category for these? If so, what is the rationale?
There's also some overlapping discussion on this in #1126
What do you think @hoeck @samchon @DZakh @M-jerez @sinclairzx81 @Lyumih @jakebailey (sorry if I missed anyone, did not mean to exclude anyone, I just went thru recent issues and PRs, feel free to tag anyone else you can think of)
I think it's fine to add ts-auto-guard since there are already similar packages in the benchmark.
But having a filter / badge for difference kinds of libraries would definitely be nice.
Btw, according to ts-auto-guard docs, they don't check that null is also typeof object. If that is the case, I think the library should be prevented from adding to the benchmark by tests.
The simplest way to add badges that comes to my mind is to add (jit) or something like this at the end of the package name
I think it fits to the name 'runtime' since the validation itself happens in runtime.