Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing the perfect TypeScript schema validation library

vriad.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Designing the perfect TypeScript schema validation library

#51

Post by coffexx »

IggleSniggle wrote: post #48
colinmcd wrote: post #20

Earlier quoted context omitted.

You can generate JSON Schema from TS with this library: https://github.com/YousefED/typescript-json-schema It's certainly conceivable to build an equivalent for Zod but you'll eventually want to validate types that aren't expressible in TS (i.e. Integer).

This looks like it generates JSON Schema, but not runtime validators?

For that you could use something like ajv. Json schema has the advantage of being usable across different languages, but it does come with the overhead of maintaining those files and keeping it in sync with your other repos.

Re: Designing the perfect TypeScript schema validation library

#52

Post by franky47 »

Adding to the pile of similar approaches, there's TypeBox [1] which uses JSON Schema as an intermediate artifact (validation can happen with ajv or other libs), and extracts static types for TypeScript.

Having the JSON Schema intermediate is useful when using Fastify [2], so that request validation can happen with less boilerplate.

[1] https://github.com/sinclairzx81/typebox

[2] https://www.fastify.io/docs/latest/Validation-and-Serializat...

Re: Designing the perfect TypeScript schema validation library

#53

Post by williamdclt »

eyelidlessness wrote: post #26
dlbucci wrote: post #13

Earlier quoted context omitted.

Yeah, that's really something that feels like it should be a part of the language, because it would be so useful!

It's explicitly one of the language's non-goals[1]. > Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata. [1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

I understand it (there's already enough to do at type level that runtime level is a non-goal), but types are purely indicative at IO boundaries. Validation still needs to happen

Re: Designing the perfect TypeScript schema validation library

#54

Post by Gehinnn »

I've been working on something similar, also struggeling with `io-ts`. However, I want the schema to be serializable (possibly compatible with json schema) so that a rich ecosystem of tools can be build upon it. There is still a long way to go though.

My library `@hediet/cli` [1] uses this technology to offer a browser based UI for CLI applications [2]. In the long term, I want to replace my use of `io-ts` with this technology in my JSON RPC implementation [3], so that I can implement something similar to Swagger for JSON RPC.

I always felt the possibilities of JSON Schema are not really explored, which I think might be due to bad design of JSON Schema (it's really hard to consider all these denormalizations, it's like HTML 20 years ago).

I'll have a more detailed look at your library once I find time!

[1] https://github.com/hediet/ts-cli/blob/master/cli/README.md [2] https://github.com/hediet/ts-cli/blob/master/cli/docs/gui.pn... [3] https://github.com/hediet/typed-json-rpc

Re: Designing the perfect TypeScript schema validation library

#55

Post by Ezku »

eyelidlessness wrote: post #49
colinmcd wrote: post #31

Earlier quoted context omitted.

I personally prefer to standardize everything as a function. It also leaves some breathing room in case I decide to include parameters as part of a future API augmentation.

I hope you'll give me the opportunity to try to convince you otherwise. I understand the context of this is that io-ts puts an onerous emphasis on FP concepts and data structures. But FP principles , when applied in an effective and usable way, are quite good. The make it easier to reason about and maintain code. One such principle is that a "function" with no parameters is a good sign that it will cause some kind of…

Very strongly agreeing with this assessment and hoping Colin will come to agree.

A zero-argument function is either a constant, or a side-effect. Given we don’t want a side-effect, exposing a constant instead of an effectful-looking function is preferable.

Re: Designing the perfect TypeScript schema validation library

#56

Post by Ezku »

colinmcd wrote: post #12
Ezku wrote: post #9

You mention creating object types with optional keys is cumbersome in io-ts. How is that solved in zod, exactly? What allows you to map `foo: union([bar, undefined])` to `foo?: bar | undefined` (note the question mark on the left hand side)? There’s nothing in the declaration to give away why this wouldn’t yield `foo: bar | undefined` which is what I believe you’d get out of io-ts. Looks useful - I would have an easi…

Good question! It wasn't easy to get the question mark on the left-hand side, but it is possible. Here's the Zod equivalent: const C = z.object({ foo: z.string(), bar: z.number().optional(), }); type C = t.TypeOf ; /* { foo: string; bar?: number | undefined } */ And here's the code that pulls this off: type OptionalKeys = { [k in keyof T]: undefined extends T[k]['_type'] ? k : never; }[keyof T]; type RequiredKeys = E…

Thanks for the reply. So, careful application of mapped types and removing the ability to type a property as `foo: bar | undefined`. I understand this is desirable a lot of times especially if you can’t affect the format of what’s being parsed, but I’m not sure this is unambiguously better.

FWIW it’s made my life easier to say the keys will always be there, but the values are possibly undefined. Less room for ambiguous interpretation.

Re: Designing the perfect TypeScript schema validation library

#57

Post by seanwilson »

Are there any plans for building validation support like this directly into TypeScript? If not, why not?

TypeScript seems designed to be incrementally added to large existing projects. Why then isn't there a standard way to validate objects coming from the untyped parts of your project?

Re: Designing the perfect TypeScript schema validation library

#59

Post by donatj »

Call me old fashioned, but "mission-critical" and "rock-solid" are inherently at odds with anything that runs a on a clients machine. Doubly so for something that runs in an interpreted language, especially one that doesn't ship with it's own interpreter to said client.

In these cases I'd far rather see an old fashioned reliable server-side application built in a language with a lot of built in safety. The less you ask the client to do, the more reliable the application.

Re: Designing the perfect TypeScript schema validation library

#60

Post by nateabele »

Also did something similar[1]. My motivations were a better API (mine is modeled off of Elm's), and better error messages: I have a use case where user's need to be shown raw, dev-tools-style interactive data dumps, with error information overlaid on top. The next version will also enable data generation from schemas.

Also, and perhaps most importantly, this library has no respect for undefined, because particularly in the context of data modeling, undefined is complete nonsense.

[1] https://github.com/ai-labs-team/ts-utils#decoder

Post reply on HN