Designing the perfect TypeScript schema validation library

98 点作者 colinmcd大约 5 年前

19 条评论

cjdell大约 5 年前

I built something like this a few months ago but struggled to explain to almost everyone except die hard TypeScript fans what the big deal was.I explained it was all about the type inference from the schema so I could make guarantees across runtime boundaries.This is what I came up with, though this library looks like it may be more comprehensive than what I wrote. Struggled to come up with a good name to represent exactly what it did...<a href="https://www.npmjs.com/package/type-safe-validator" rel="nofollow">https://www.npmjs.com/package/type-safe-validator</a>The ability of the TypeScript compiler to allow this stuff continues to make it one of my favourite languages to work with, despite it still being JavaScript underneath.

评论 #22563507 未加载

评论 #22563169 未加载

Gehinnn大约 5 年前

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] <a href="https://github.com/hediet/ts-cli/blob/master/cli/README.md" rel="nofollow">https://github.com/hediet/ts-cli/blob/master/cli/README.md</a> [2] <a href="https://github.com/hediet/ts-cli/blob/master/cli/docs/gui.png" rel="nofollow">https://github.com/hediet/ts-cli/blob/master/cli/docs/gui.pn...</a> [3] <a href="https://github.com/hediet/typed-json-rpc" rel="nofollow">https://github.com/hediet/typed-json-rpc</a>

hn_throwaway_99大约 5 年前

While I think this is pretty cool, given his use case (wanting to use a strongly typed client and server), I can't see why one wouldn't just use GraphQL with TypeScript on both the client and server. I've done this and I love it:1. Define the GraphQL interface with GraphQL's typedef language. GraphQL then takes care of validating all the request and responses at runtime.2. Use something like <a href="https://github.com/dotansimha/graphql-code-generator" rel="nofollow">https://github.com/dotansimha/graphql-code-generator</a> to generate all your TypeScript types from your GraphQL schema. Place these types on your resolvers and then you get compile-time type checking.3. Since GraphQL actually exposes your schema as part of the endpoint, clients can use the same tool to keep their TypeScript types in sync, and get the same typing benefits when writing the client code.

评论 #22567396 未加载

评论 #22677993 未加载

eyelidlessness大约 5 年前

This is great. I recently built a fairly large amount of functionality around io-ts, adding support for mixed required/optional fields, eliminating the need to deal with `Either` monads, and a whole lot of other stuff that's mostly just relevant to my company's usage. I think if this had been available at the time I was looking for an underlying library, it would have been a no brainer to choose this one.Worth noting, another option is Runtypes[1], which also looks great. I can't remember off the top of my head why I ultimately picked io-ts over Runtypes, but it's another one for folks to consider (and I'd be curious what the Zod author thinks of it).<a href="https://github.com/pelotom/runtypes" rel="nofollow">https://github.com/pelotom/runtypes</a>

评论 #22562334 未加载

评论 #22562891 未加载

评论 #22563238 未加载

评论 #22562987 未加载

jrimbault大约 5 年前

I'd really like something like a compiler step/plugin to generate the validators from the declared typescript types.

评论 #22562665 未加载

评论 #22562584 未加载

评论 #22562581 未加载

franky47大约 5 年前

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] <a href="https://github.com/sinclairzx81/typebox" rel="nofollow">https://github.com/sinclairzx81/typebox</a>[2] <a href="https://www.fastify.io/docs/latest/Validation-and-Serialization/" rel="nofollow">https://www.fastify.io/docs/latest/Validation-and-Serializat...</a>

nateabele大约 5 年前

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] <a href="https://github.com/ai-labs-team/ts-utils#decoder" rel="nofollow">https://github.com/ai-labs-team/ts-utils#decoder</a>

评论 #22567639 未加载

janpot大约 5 年前

You might want to take a look at ts-json-validator [1] as well. It creates type-aware validators for json-schema.[1] <a href="https://github.com/ostrowr/ts-json-validator" rel="nofollow">https://github.com/ostrowr/ts-json-validator</a>

random_savv大约 5 年前

There is also class-validator, which I've used and I find elegant and working well:<a href="https://github.com/typestack/class-validator" rel="nofollow">https://github.com/typestack/class-validator</a>

评论 #22562829 未加载

__michaelg大约 5 年前

No mention of runtypes which looks pretty similar? <a href="https://github.com/pelotom/runtypes" rel="nofollow">https://github.com/pelotom/runtypes</a>

评论 #22562726 未加载

sakagami0大约 5 年前

Wow I made the same thing that I put v1 up a couple days ago.<a href="https://github.com/tetranoir/presi" rel="nofollow">https://github.com/tetranoir/presi</a>A main difference is I tried to get rid of having a separate line to create the Type and I tried to get rid of having to learn a new libary's api as much as possible.

评论 #22562842 未加载

seanwilson大约 5 年前

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?

评论 #22567863 未加载

mirekrusin大约 5 年前

Something similar, but for flow and focused more on functional combinators <a href="https://github.com/appliedblockchain/assert-combinators" rel="nofollow">https://github.com/appliedblockchain/assert-combinators</a>

评论 #22563760 未加载

AriaMinaei大约 5 年前

I've used a few similar libraries [0][1][2] and wrote one for a personal project. If we categorize them as embedded DSLs for runtime type checking with some support for static interop, they all share three major flaws:1. Sub-optimal developer experience: significantly noisier syntax compared to pure typescript, convoluted typescript errors, and slower type checking.2. Unfixable edge cases in static type checking: Features like conditional types work less reliably on the types produced by the library.3. Some typescript features can't be supported in the library (again, conditional types).I think a better way to approach the runtime+static type checking is to do it as a babel plugin, which would fix the DX and edge-case problems and also gracefully degrade in the case of typescript features that can't work in runtime.Since babel can now parse typescript, it is trivial to write a babel plugin that takes regular typescript files and converts their type annotations into runtime values [4]. Those values can then be fed into a simpler type checking library, giving us runtime type checking on top of the native static type checking experience.[0] <a href="https://github.com/gcanti/io-ts" rel="nofollow">https://github.com/gcanti/io-ts</a>[1] <a href="https://github.com/pelotom/runtypes" rel="nofollow">https://github.com/pelotom/runtypes</a>[2] mobx-state-tree also has a schema validation library that works to some extent statically: <a href="https://github.com/mobxjs/mobx-state-tree/" rel="nofollow">https://github.com/mobxjs/mobx-state-tree/</a>[3] <a href="https://github.com/gcanti/io-ts#branded-types--refinements" rel="nofollow">https://github.com/gcanti/io-ts#branded-types--refinements</a>[4] <a href="https://gist.github.com/AriaMinaei/2f1229178abad4363f5180db238dd8b3" rel="nofollow">https://gist.github.com/AriaMinaei/2f1229178abad4363f5180db2...</a>

manuisin大约 5 年前

A while ago, I used this library called ts-interface-builder to generate runtime validation functions from TS types. It worked really well, I was able to use the types from my front-end without any modifications for back-end validation.Also, used the inferred response types from endpoint functions and passed them back to the front-end to use with front-end fetch calls. This was probably the biggest improvement in terms of productivity and improving accuracy. Imagine every time you change an endpoint's response, any fetch calls that are impacted would just show errors at compile time/in your editor.

chris_st大约 5 年前

Possibly stupid question, but why does the dog array validate:<pre><code> const dogsList = z.array(dogSchema); dogSchema.parse([ { name: 'Cujo', neutered: null }, { name: 'Fido', age: 4, neutered: true }, ]); // passes </code></pre> Since 'Cujo' doesn't have an age? Assuming it's the same dogSchema as in the previous block, age is required, right?Oh, and a minor typo: This lets you confidently This way you can confidently....

评论 #22563020 未加载

评论 #22562683 未加载

Ezku大约 5 年前

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 easier time introducing this than io-ts.

评论 #22562570 未加载

评论 #22562534 未加载

adriancooney大约 5 年前

Can't seem to spot a link to Zod's code Colin. Fancy making it a bit more obvious in the post?Edit: Found it: <a href="https://github.com/vriad/zod" rel="nofollow">https://github.com/vriad/zod</a>

评论 #22562200 未加载

donatj大约 5 年前

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.

评论 #22567269 未加载