Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression. Learn more →
Zod Alternatives
Similar projects and alternatives to zod
-
-
-
Appwrite
Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
-
TypeScript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
-
-
Superstruct
A simple and composable way to validate data in JavaScript (and TypeScript).
-
ajv
The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
-
-
Prisma
Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
-
joi
The most powerful data validation library for JS [Moved to: https://github.com/sideway/joi] (by hapijs)
-
react-hook-form
📋 React Hooks for form state management and validation (Web + React Native)
-
-
proposal-record-tuple
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
-
-
-
-
-
-
typescript-runtime-type-benchmarks
📊 Benchmark Comparison of Packages with Runtime Validation and TypeScript Support
-
typescript-eslint
:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
-
Sonar
Write Clean JavaScript Code. Always.. Sonar helps you commit clean code every time. With over 300 unique rules to find JavaScript bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.
zod reviews and mentions
-
Backend C# + Frontend React?
If you still decide to keep them separate, do yourself a favor and use Zod for your schema validation on the front-end. It'll save you the trouble of messy type definitions and it's honestly a breeze to work with
-
Roll for your kingdom: First experiment with svelte
Besides svelte/sveltekit, it uses Zod and tRCP connected to a Supabase postgres database via Prisma and deployed on vercel.
-
GitHub - ernestoittig/xod: Parsing and schema validation library for Elixir
It's kind of a shameless rip of a Typescript library call Zod (hence the name) but reworked to be even more functional to work with Elixir.
-
Building a Fullstack Next.js app -> tRPC(v10), Tailwind, Prisma
Zod - is a TypeScript-first schema builder for data validation and parsing. It's a great tool for validating data before it gets to the database. It's very easy to use and it's very fast.
-
Using Zod with React hook form using typescript
and there's a lot to do with zod and use form hook you can look at the documentation react hook form zod and shout-out to Austin Shelby for great video
-
TypeScript 5.0
> how would the browser check and enforce my types?
If this is what you're looking for, you aren't going to get it with TypeScript, even if you could parse it in the browser. It might be possible to port or build a TypeScript parser that runs in the browser (it might even be done already) but this would mean sending a LOT of code over the wire for something that was designed as a static analysis tool.
You can use runtime validation libraries like https://zod.dev/.
JS will eventually include its own type system so that you will be able to write typed code and have it run in the browser. However, even then the types won't be checked at runtime. You'll still have to rely on a tool like `tsc` to type check your code.
-
ArkType: TypeScript's 1:1 validator, optimized from editor to runtime
Hey everyone! I started working on ArkType about 15 months ago, which at the time was an experiment to determine whether a TypeScript syntax parser written using TS's own generic types could be performant.
To my surprise, after a few months of iteration, it turned out it was possible to parse and provide fluid completions for scopes consisting of hundreds of cyclic types (see https://arktype.io/img/typePerf.mp4).
At this point, I started working on an "isomorphic" parser that would allow definitions that looked like native TypeScript syntax to be parsed and enforced at compile-time via TS and at runtime in JavaScript using parallel static and dynamic implementations (see https://github.com/arktypeio/arktype#how). This includes syntactic and semantic validation that your editor can update in real-time as you write a definition (if you want you can try messing around with a definition and corresponding input data in-browser at https://arktype.io/try).
Though as a full type system the library has lots of potential applications, the most obvious is for type-safe data validation as an alternative to approaches like Zod that rely on chained functions. Honestly I just think the fact that TypeScript can parse itself is cool in its own right, but given the prevalence of questions about how ArkType is different/better than existing libraries, I've taken the liberty of summarizing a few of what I believe are the most compelling points preemptively:
- Having definitions that are inferred 1:1 means you'll be hovering to see types less
- Most definitions are just objects and strings and can be easily serialized and eventually could even be used to validate data across multiple languages. Validators that rely on chaining will never be able to do this.
- On average, definitions are about 50% shorter than traditional chained syntax.
- Zod recently announced they were deprecating discriminated unions (see https://github.com/colinhacks/zod/issues/2106) because it was hard to maintain given their architecture. Not only are they supported in `arktype`, they're supported implicitly- you don't even have to tell us what keys to look at.
- The discriminated unions point is really just a special case of a much more general advantage: `arktype` is not just a validator- it's a type system. If we can deeply intersect arbitrary types, optimize them, and determine assignability, we can use all of that to make discrimination much easier (being able to "discriminate" is equivalent to having some common path that has an intersection of `never`)
- Zod claims it's impossible to infer recursive types due to a limitation of TS (see https://zod.dev/?id=recursive-types) and cannot handle cyclic data. ArkType can directly infer cyclic and recursive types and validate cyclic data.
The point of this is not to say Zod is not a good library. It significantly improved inference capabilities and DX relative to the previous generation of validators like Yup. It also still has some features we haven't yet implemented (primarily stuff like `pick` and `merge` as I'm working on adding support for generics).
Plus, we're still on `1.0.9-alpha`, so if I needed a validator for my critical production software, I'd probably go with `zod`.
That said, I do think `arktype` has some fundamental advantages that mean in the long term, it's a better approach to invest in. My current focus in preparing for a stable release is adding docs, optimizing runtime perf, and publishing benchmarks (using similar techniques to https://github.com/sinclairzx81/typebox, so should land somewhere between 50-100x faster than non-optimized validators like Zod).
Do you think that makes sense as a next priority? Do you think any of this makes sense at all, or have I just been coding in TS's type system long enough that my sanity has begun to erode? Agree or not with any of it, I'd love to hear your thoughts :-)
- David
-
When should I use runtime checks (and which runtime checker should I use)?
In terms of which runtime checker I should use. The first tutorial I saw suggested 'Zod', doing a bit more searchign yielded other options such as 'runtypes'.
-
All JavaScript and TypeScript features of the last 3 years explained
You can use discriminated unions with TS (https://antman-does-software.com/typescripts-discriminated-u...), and you can even parse them from unknown data using tools like zod (https://zod.dev/?id=discriminated-unions), io-ts, or the likes.
I can't think of anything I can do in .NET (which has runtime types) that I can't do in TS with the help of a library or two.
-
The Last Breaking Change | JSON Schema Blog
Additionally Zod is also undergoing breaking changes, as any library would. (Example) As a comparison, it seems moot.
-
A note from our sponsor - InfluxDB
www.influxdata.com | 25 Mar 2023
Stats
colinhacks/zod is an open source project licensed under MIT License which is an OSI approved license.