-
TS makes no guarantees about type representation. When doing type level programming you have to work very hard to ensure you don’t leak implementation details into your inferred type signatures, and the TS team has explicitly said that they may break the tricks that people use at any time.
-
SurveyJS
JavaScript Form Builder with No-Code UI & Built-In JSON Schema Editor. Add the SurveyJS white-label form builder to your JavaScript app (React/Angular/Vue3). Build complex JSON forms without coding. Fully customizable, works with any backend, perfect for data-heavy apps. Learn more.
-
We already do some black magic wizardry with decorators, why not do this too? If it's a flop, at least it will have the company of namespace, enum and interface to hang out with. The typia library already does this and the performance results are a bit staggering, it doesn't support TypeScript 5.0 yet and requires 3rd party tools to shim a modification into the tsc command but it feels like something that should be a part of TypeScript right now.
-
typescript-runtime-type-benchmarks
📊 Benchmark Comparison of Packages with Runtime Validation and TypeScript Support
First, they're not fast (runtime type checking benchmarks).
-
A quick check of npmtrends of zod vs ajv suggests you're not alone either. I think AJV is an interesting choice too, it's one of the few runtime type checking libraries that creates the type according to a particular standard that transcends beyond the scope of TypeScript. Namely JSON Schema and JSON Type Definition.
-
In essence, features of the language made for static type checking at compilation are possibly being left favour of tools that act like a superset of the language that provide the static build type checking and offer runtime type checking too. An example I recently saw was the trpc-openapi package which uses Zod for creating the types of the schema for the http request and responses, it takes a zod schema as that is what it can use when compiled to JavaScript to generate the types for the openapi file at runtime, there's scarcely a type or interface in sight when using it but you have full type safety.
-
I'll admit, it is easy to assert that the TypeScript language should not be involved in the matters of packages but I also wonder if we're moving towards a point where interfaces will be as common as namespaces and whether or not it would be sensible for the language to incorporate such type assertions into the language formally, after all, it already compiles to various forms of JavaScript and there is a stage 1 proposal submitted to the TC39 committee to give JavaScript pattern matching. If adopted, wouldn't it make sense to allow TypeScript to compile a type into a type guard for the native JavaScript pattern matcher?
-
ttype-safe
TypeScript runtime type validator generator that creates validation functions from TypeScript types with custom validation rules defined using JSDoc comments.
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
This is my currently preferred way, you can check out the repo description of ts2typebox to see what I mean
-
Well, I do provide extensibility for those bullet points you've listed to varying degrees (both schema and type representation), as well as offering a reference implementation for expressing a entirely different schema specification under the type system (specifically RFC8927 / JSON Type Definition). Reference implementation here. As for JSDoc, It's supported in code hints.
