Yes, there are limits on what string literals can precisely represent, but we've tried to be pragmatic about trade offs around clarity, concision and performance.
Subexpressions like `\\w` or `[a-Z]` would just be inferred as `${string}`, but that doesn't mean the inference won't be useful. For example:
ArkType 2.0 is a no-setup solution for schema validation with a new style of type-safe API that parallels native type syntax while offering validation functionality like Zod or Yup.
It also brings types to runtime in a way they've never been available before. They can be introspected and compared just like `extends` in native TS.
Thanks for your patience, and I couldn't be more hyped to see what you do with it!
Since `.ts` extensions were in alpha, our repo has been set up so that you can switch between Node and Deno seamlessly in-editor and continue developing with no config or source changes.
Personally, I found all the `npm` integration stuff to be a bit overkill for what we were looking for, and honestly Deno's network requests while installing from npm were constantly flaking out in our CI. We ended up just disabling it via Deno's `--no-npm` flag (https://github.com/denoland/deno/issues/17916) and reverting back to a simple set of import_maps to get the node deps we needed. Works like a charm!
Massive release! `const` generic parameters in particular have been a god-send for our repo’s static inference (https://github.com/arktypeio/arktype) where previously we were forced to constantly rely on complex narrowing logic based on extends checks.
I look forward to the day when we support 5.0 as our minimum version and replace all of them with `const` generics for 1:1-inferred definitions like this:
Plus we’ll finally be able to remove the crazy hack we had to write to allow ts-morph to make type assertions on our codebase by transforming all of our `.ts` imports to `.js` in a virtual file system, which now that I think of it I’m probably looking forward to deleting even more XD
Great work, and looking forward to what comes next!
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 :-)
We are using Zod very heavily currently in a fairly complex set of models where Generics are needed and used heavily. Right now, we are having to perform quite a few 'tricks' with Zod to meet our needs. I am very excited to understand what is the plan with Generics in ArkType, what will be possible, what will the be the DX?
Have you seen ArkType (https://github.com/arktypeio/arktype)? Similar parse-based approach to validation with a significantly more concise definition syntax:
const info = type({
name: "string>0",
email: "email"
})
Hey everyone! I've been working on a new approach to type-first validation and would love to get some feedback or answer any questions you have!
By far the most common question I get is "why use this over existing validators like Zod?" so I'll preemptively address it:
- There's a comparison between Zod and ArkType for defining a simple type under "Concision" on our docs site (https://arktype.io). The definition is much shorter and the inference is cleaner and more intuitive. This is not a cherry-picked case. The examples are from Zod's documentation and ArkType's syntax and type hints are highly optimized for clarity.
- Zod recently announced they were deprecating discriminated unions 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)
- Most ArkType 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.
- Zod claims the following in their docs:
"You can define a recursive schema in Zod, but because of a limitation of TypeScript, their type can't be statically inferred. Instead you'll need to define the type definition manually, and provide it to Zod as a 'type hint'."
They go on to mention:
"passing cyclical data into Zod will cause an infinite loop"
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.8-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.
ArkType is a library for defining runtime types using TypeScript syntax that can be inferred 1:1.
Each character you type is instantly validated both syntactically and semantically using TypeScript's own type system, so you know exactly what to expect from editor to runtime.
Plus, since most definitions are just objects and strings, they can actually be serialized and eventually even shared across languages.
I would love to hear your thoughts on the concept and syntax decisions as I prepare to freeze the API for our first stable 1.0 release (we're currently at 1.0.5-alpha).
Subexpressions like `\\w` or `[a-Z]` would just be inferred as `${string}`, but that doesn't mean the inference won't be useful. For example:
expression: regex("^\\w+@\\w+\\.\\w+$") type: Regex<`${string}@${string}.${string}`>