feat: add typia

[samchon]

Related issues:

• Add typia #898
• Add @Typia #1019
• Add @Typia to typescript-runtime-type-benchmarks samchon/typia#473

I can't see benchmark result because I am using Windows PC and this repo be broken on the Windows PC.

Hope to be the fastest.

[samchon]

Passed to test program in my local.

[samchon]

As other validation libraries do not allow undefined value assignment on superfluous peoperty, typia also blocked it by supporting extra options.

interface Member {
    id: string;
    name: string;
    age?: number;
}

const member: Member = {
    id: "some-id",
    name: "some-name",
    age: undefined
};
// possible in typia
// however, not possible in other validators
// therefore, added an extra option blocking the undefined value to ensure same condition

[moltar]

@samchon The tests pass! 🎉

But now that I understand typia more, I am a bit hesitant to merge this, as I am not 100% confident this package goes with the theme of the rest of the packages here. The theme was defining types as code, and then allowing TypeScript to infer the types. However, I do like the typia approach, and especially, because it is so much faster. I am just wondering if perhaps we need an entirely new category of validators now?

@hoeck Thoughts?

[samchon]

Well, this repository already had accepted ts-runtime-checks which requires ttypescript, too.

Also, most validator libraries listed on here repo be broken just by using a little bit complicate type like recursive or union types. For example, above ts-runtime-checks be broken when nullable object type comes and occurs critical error if recursive type be used. Furthermore, every other validator libraries cannot understand complite union type like json schema structure.

Such imperfection is the reason why I have developed typia unless there had been lots of similar libraries. Therefore, I hope you to add more test case structures. Don't you have any plan to add more test case structures like below?

https://github.com/samchon/typia/tree/master/test/structures

[hoeck]

@moltar Yeah, instead of using function composition, it directly parses interfaces at compile time, similar to the runtime type reflection that deepkit does. Using that info, it generates code similar to e.g. spectypes.

So for me, typia fits the runtype category, event though it is much more meta than more conventional (zod, valita) approaches:

✔️ the type is only written out once
✔️ a validator / casting function is provided

There are even more unconventional approaches to runtypes out there, e.g. arktype that mixes function composition and template literal types.

Having them all in a single basic benchmark is IMHO a really useful resource and to me would be more important than strict inclusion criteria. It helps comparing all the different approaches, is a good showcase for the TS ecosystem and helps developers new to runtypes to maybe pick a good library that fits their use case.

I am just wondering if perhaps we need an entirely new category of validators now?
I'd love to have a feature matrix of all benchmarked runtypes embedded in the benchmark graph, e.g. "uses runtime eval", "requires compilation step", "# of dependencies", "supports recursion" etc. to be able to better compare the different libraries and their perf / complexity trade offs.

[hoeck]

@samchon having more benchmark cases would be great but on the other hand implementing them for all libraries and presenting (weighing?) the resulting data in a useful way would be a lot of work. I'd love to do it but my time is quite limited.

[moltar]

Ok, now that I am more fresh-minded & after reading @hoeck take, I agree this fits with the theme!

Don't you have any plan to add more test case structures like below?

There are no plans, but definitely something I'd like to see!

I think we have an issue tracking it already, and you opened it: #900