DEV Community: andrew jarrett

Do anything with a Valibot schema!

andrew jarrett — Sat, 27 Sep 2025 08:25:41 +0000

andrew jarrett

Sep 15 '25

Introducing: @traversable/valibot

#typescript #javascript #webdev #opensource

Comments 10

4 min read

Introducing: @traversable/valibot

andrew jarrett — Mon, 15 Sep 2025 23:47:10 +0000

A few weeks ago I released a TypeScript library called @traversable/valibot.

This post covers what the library does, and highlights a few of its unique features.

Cover photo credit:
Astro Boy Schematics (鉄腕アトム), Tezuka Productions

Note:
Currently @traversable/valibot only works with the latest version of Valibot (v1.1).

What makes @traversable/valibot different?

@traversable/valibot can be used in 2 ways:

Pick one of over 15 transformers available off-the-shelf
Hand-roll your own custom transformer

Off-the-shelf

ᯓ🚀 `vx.check`

Turn a Valibot schema into a super-performant type-guard
📖 Performance profile

ᯓ🚀 `vx.deepClone`

Converts a Valibot schema into a “deep copy” function
📖 How I built JavaScript's fastest deep clone function

ᯓ🚀 `vx.deepEqual`

Converts a Valibot schema into a “deep equal” function
📖 How I built JavaScript's fastest deep equals function

ᯓ🚀 `vx.toString`

Converts a Valibot schema into a string
Useful for testing, codegen, sanity checking

ᯓ🚀 `vx.toType`

Converts a Valibot schema into a TypeScript type
🏷️ Preserves schema metadata as JSDoc annotations

ᯓ🚀 `vx.defaultValue` ✨new!✨

Derive a configurable default value from a schema
Designed for schema-driven forms on the frontend

ᯓ🚀 `vx.makeLens` ✨coming soon!✨

🔍 Focus nested values with lenses (getters/setters)
🌈 Reify control flow with prisms (pattern-matchers)
⛰️ Map over containers with traversals (for-loops)
🧱 Stack them together with function composition

Roll your own

ᯓ🚀 `vx.fold`

All the off-the-shelf transformers that @traversable/valibot ships are powered by vx.fold.

Under the hood, the library uses an abstraction called recursion schemes that make implementing recursion simple and fun.

To demonstrate, I used it to implement a mock data generator.

The implementation is so minimal (25 lines!) that I've embedded it here, in its entirety:

Note:

To keep things simple, this is a partial implementation.

For a more robust version, see this StackBlitz.

Bonus: @traversable/valibot-test

@traversable/valibot-test is a testing library built specifically for library authors who are building on top of Valibot.

Under the hood, it uses a TypeScript library called fast-check to generate random Valibot schemas.

Being able to generate random schemas turns out to be incredibly useful for fuzz testing.

For example, here we use it to test that our valibotToFaker function always generates valid data:

💡 Tip:

Scroll up in the terminal panel to see the generated schemas + mock data!

Updates

Update: as of yesterday, @traversable/valibot is part of the Valibot ecosystem!

adds @traversable/valibot and @traversable/valibot-test to ecosystem #1298

ahrjarrett posted on Sep 07, 2025

Hello Valibot maintainers!

This PR adds 2 libraries to the ecosystem:

These libraries were primarily built for developers who are building tools on top of Valibot, but can also be used for one of the 10+ off-the-shelf transformers that we currently support.

Happy to talk more about the library if you have any questions!

View on GitHub

adds @traversable/valibot and @traversable/valibot-test to ecosystem #1298

ahrjarrett posted on Sep 07, 2025

Hello Valibot maintainers!

This PR adds 2 libraries to the ecosystem:

These libraries were primarily built for developers who are building tools on top of Valibot, but can also be used for one of the 10+ off-the-shelf transformers that we currently support.

Happy to talk more about the library if you have any questions!

View on GitHub

The Valibot ecosystem is by far the most welcoming and collaborative TypeScript schema community out there, so I'm super proud to be able to contribute back ☺️.

Closing thoughts

Thanks for reading!

If you have any feedback, feature requests, or questions, feel free to open an issue or start a discussion.

Introducing: @traversable/zod

andrew jarrett — Tue, 02 Sep 2025 13:10:19 +0000

A few weeks ago I released a TypeScript library called @traversable/zod.

This post covers what the library does, and highlights a few of its unique features.

Note:
Currently @traversable/zod only works with the latest version of Zod (v4).

Cover photo credit:
Jack Noble, Mob Psycho 100 モブサイコ100

What makes @traversable/zod different?

@traversable/zod can be used in 2 ways:

Pick one of over 25 transformers available off-the-shelf
Hand-roll your own custom transformer

Off-the-shelf

ᯓ📦 `zx.check`

Converts a Zod schema into a super-performant type-guard
📖 Performance profile

ᯓ📦 `zx.deepClone`

Converts a Zod schema into a "deep copy" function
📖 How I built JavaScript's fastest deep clone function

ᯓ📦 `zx.deepEqual`

Converts a Zod schema into a "deep equal" function
📖 How I built JavaScript's fastest deep equals function

ᯓ📦 `zx.deepPartial`

Makes all the properties of a Zod schema optional
📖 Zod drops deepPartial in v4

ᯓ📦 `zx.toString`

Converts a Zod schema into a string
Useful for testing, codegen, sanity checking

ᯓ📦 `zx.toType`

Converts a Zod schema into a TypeScript type
Preserves schema metadata as JSDoc annotations

ᯓ📦 `zx.makeLens`

🔍 Focus nested values with lenses (getters/setters)
🌈 Reify control flow with prisms (pattern-matchers)
⛰️ Map over containers with traversals (for-loops)
🧱 Stack them together with function composition

Roll your own

ᯓ📦 `zx.fold`

All the off-the-shelf transformers that @traversable/zod ships are powered by zx.fold.

Under the hood, the library uses an abstraction called recursion schemes that make implementing recursion simple and fun.

To demonstrate, I used it to implement toJsonSchema.

The implementation is so minimal (28 lines!) that I've embedded it here, in its entirety:

Note:

I specifically chose toJsonSchema because multiple libraries already exist that do this, including Zod itself.

The goal is to showcase how you can use zx.fold to build a library of your own.

Closing thoughts

Thanks for reading!

If you have any feedback, feature requests, or questions, feel free to open an issue or start a discussion.

Is your code optimized for V8's JIT compiler?

andrew jarrett — Tue, 05 Aug 2025 10:54:16 +0000

Ever wondered if your code is optimized for V8's just-in-time compiler?

Here's a neat trick: use the Chrome DevTools. If V8 can "see" the structure ahead of time, that's a signal that you're on the right track.

Probably the easiest way to de-optimize your code is to use recursion. Recursion does not preserve structure.

And if you think about it, that makes sense. How could it? We'd need to solve the halting problem first.

How to build JavaScript's fastest “deep clone” function

andrew jarrett — Wed, 30 Jul 2025 01:34:07 +0000

This is a longer-form article about how I built JavaScript's fastest “deep clone” function.

Last time when I talked about implementing “deep equal”, I ended by basically telling readers to draw the rest of the owl.

This time let's get in the weeds.

If you haven't already, read through the post on implementing JavaScript's fastest “deep equal”. It's a short read (~5 minutes), and we'll be picking up where we left off in this post.

tl;dr

The implementation we'll be talking about today is:

10-50x faster than Lodash.deepClone
20-120x faster than window.structuredClone

If you're skeptical, you can run the benchmarks yourself on Bolt by typing npm run bench in the terminal.

Before we get into the how, let's first make sure we're on the same page about the problem we're trying to solve.

Disclaimer:

You might not need a deep copy.

Even if cloning were “free” (instantaneous), you still pay for the memory allocation.

Other solutions, such as structural sharing, can help you balance that cost, and could very well be a better fit for your use case.

As always, make sure you're aware of the tradeoffs, and think critically before you go around minting new copies of your data.

Let's get into it.

The problem

Managing shared references to mutable data is hard.

And JavaScript offers little help here: the syntax for mutating a value (=) is identical to the syntax for binding a variable (=), and similar to the syntax for comparing two values (==).

If you're an experienced JavaScript developer, you've probably learned to be hyper-vigilant about preventing accidental mutation.

Sometimes, though, you need a guarantee. Sometimes you need to make a copy.

So what's the problem?

Copying data is slow.

Part of the problem is that allocating memory takes time. This part is, to some extent, unavoidable.

Part of the problem is that the algorithm is slow. This is the part we can change.

A “naive” solution

How can we make deep cloning fast?

As usual we start with a naive solution.

Let's say we're working with the following data model:

const UserSchema = {
  type: 'object',
  properties: {
    firstName: { type: 'string' },
    lastName: { type: 'string' },
    addresses: {
      type: 'array'
      items: {
        type: 'object',
        properties: {
          street1: { type: 'string' },
          street2: { type: 'string' },
          city: { type: 'string' }
        }
      }
    }
  }
}

Here's what a user looks like:

const sherlock = {
  firstName: 'Sherlock',
  lastName: 'Holmes',
  addresses: [{
    street1: '221 Baker St',
    street2: 'Apartment B',
    city: 'London'
  }]
}

Let's practicing our “unlearning” skills and hardcode the solution, like we did last time.

type User = {
  firstName: string
  lastName: string
  addresses: {
    street1: string
    street2: string
    city: string
  }[]
}

function deepClone(user: User): User {
  return {
    firstName: user.firstName,
    lastName: user.lastName,
    addresses: user.addresses.map((value) => ({
      street1: value.street1,
      street2: value.street2,
      city: value.city
    }))
  }
}

Let's benchmark it.

Benchmarking our naive solution

If you'd like to run the benchmarks yourself, you can do so in the Bolt sandbox.

Here's the breakdown:

Lodash                       205.09 µs/iter 203.25 µs  █
                    (173.25 µs … 883.04 µs) 829.71 µs ▄█
                    ( 14.52 kb … 725.08 kb)  65.87 kb ██▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
                  4.49 ipc (  0.66% stalls)  99.07% L1 data cache
        621.43k cycles   2.79M instructions  33.01% retired LD/ST (920.05k)

deepClone                      5.40 µs/iter   5.45 µs            ▂█
                        (5.19 µs … 5.65 µs)   5.61 µs          ▃███
                    (  0.83  b …   1.97 kb) 169.67  b █▃▇█▃▃▁▃▁████▇▇▅▁▃▅▃▃
                  5.68 ipc (  1.07% stalls)  99.62% L1 data cache
         17.05k cycles  96.82k instructions  37.40% retired LD/ST ( 36.21k)

          ┌                                            ┐
Lodash    ┤■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 205.09 µs
deepClone ┤ 5.40 µs
          └                                            ┘

          ┌                                            ┐
                   ╷┌┬                                 ╷
   Lodash          ├┤│─────────────────────────────────┤
                   ╵└┴                                 ╵
           ┬
deepClone  │
           ┴
          └                                            ┘
          5.19 µs          417.45 µs           829.71 µs

summary
  deepClone
   37.98x faster than Lodash

Yep, it's fast. It could probably be faster, but this blogpost isn't about micro-optimization – it's about drawing the rest of the owl.

Two call outs, before we move on:

Consistency

Notice how inconsistent Lodash is. Here's the range:

173.25 µs … 883.04 µs

883.04 / 173.25 = 5.1

That's a lot of variance. Depending on the run, Lodash sometimes took 400% more time to do the job.

Compare that to our implementation:

(5.19 µs … 5.65 µs)

5.65 / 5.19 = 1.1

By comparison, our implementation deviated by only 10%.

So in addition to being faster, it's also more predictable.

That makes sense – ours knows the shape of the data it will receive, so its performance is similarly knowable.

Instruction count

Notice how much work Lodash is doing:

621.43k cycles   2.79M instructions

Ours:

17.05k cycles  96.82k instructions

That also makes sense. Our implementation doesn't need to introspect the data, or make any decisions. All it does is clone data.

Interestingly, the difference in instruction count differs by nearly the same factor as time spent:

Lodash:                2.79M instructions
Ours:   96_820 * 37x = 3.58M instructions

Implementing JavaScript's fastest “deep clone”

Like last time, we'll use a “spec” (JSON Schema) to front-load the cost, so we only have to pay it once.

And, like last time, we'll use the schema to build up our program as a string, which we can then pass to the built-in Function constructor.

If you haven't seen this pattern before, my previous post talks about the pattern and why it works.

In other words, this is what we want:

const deepClone = Function('data', `
  return {
    firstName: data.firstName,
    ...data.lastName !== undefined && 
    ({ lastName: data.lastName }),
    addresses: data.addresses.map((value) => ({
      street1: value.street1,
      ...value.street2 !== undefined &&
      ({ street2: value.street2 }),
      city: value.city
    }))
  }
`)

Mapping schema to syntax

Our implementation will take a JSON Schema as input, and return a big string.

We'll have to use recursion at some point, but postpone that part for as long as we can.

First, we need to decompose our big problem into smaller sub-problems.

When it comes to recursion, it's almost always easier to start at the leaf nodes.

Leaf nodes

How should we handle strings nodes?

Let's peek at our implementation again:

function deepClone(data) {
  return {
    firstName: data.firstName
    //         𐙘____________𐙘
    //              here
  }
}

If we're at a string node, we return the value at that address, in this case, the string data.firstName.

Which brings us to our first problem: how do we get the path? How do we know to return data.firstName, and not data.lastName, or data.x.y.z for that matter?

Continuation passing style (CPS)

If you're like me, your first thought might have been to create a local “path” variable, or add a “context” parameter, where we keep track of the path to our data.

That would work, but on the other hand, that sounds tricky. Implementing that will require a lot of “top-level” coordination, which (speaking from experience) is brittle and tricky to debug (if we screw up the coordination, we'll need to start at the top, and work our way down).

Alternatively, we could punt on all that, and make our implementation a function that accepts the path as an argument. That puts the problem of "building up a path" much closer to where we'll actually be using it.

type Builder = (path: string[]) => string

const joinPath: Builder = (path) => path.reduce(
  (acc, cur) => `${acc}.${cur}`,
  ''
)

const cloneString: Builder = (path) => joinPath(path)

That's actually all we need to do for the leaf nodes.

Array nodes

Okay, let's do arrays.

For arrays, our implementation will need to return a function that accepts a path, and returns a string.

In JSON Schema, arrays are represented like this:

{
  type: 'array',
  items: { type: 'string' }
}

But in our case, since we're working from the bottom up, { type: 'string' } will be a function, instead:

{
  type: 'array',
  items: Builder
  //     𐙘_____𐙘
  //         we already replaced the string node
  //         with `cloneString`
}

So we'll need to call it:

const cloneArray
  : (builder: Builder) => Builder
  = (builder) => (path) => joinPath(path) + 
    `.map((value) => (${builder(['value'])}))`

In other words, our array cloner will be called with its child node (builder) as an argument, then, since it's a Builder, it receives the path from its parent.

It then passes a new path (the string "value") down to its child, since its children don't need to care about the full path from the root anymore.

If you're still confused, it might help to look at our original implementation again:

{ 
  // ...
  addresses: data.addresses.map((value) => ({
    //                           𐙘___𐙘
  }))
}

That's actually all we need to do for arrays.

Object nodes

Objects will be a little trickier, but not by much.

Here's the JSON Schema for object schemas:

{
  type: 'object',
  properties: {
    street1: { type: 'string' },
    street2: { type: 'string' },
    city: { type: 'string' }
  }
}

Since we're building from the bottom-up, here's what our objects schemas will look like, mid-traversal:

{
  type: 'object',
  properties: {
    street1: Builder,
    street2: Builder,
    city: Builder
  }
}

In other words, instead of receiving a single builder as a child, we'll be receiving a record whose values are each builders.

We'll also need to call each of the builders with its key appended to the end of the path. Like this:

const cloneObject
  : (builders: Record<string, Builder>) => Builder
  = (builders) => (path) => {
    const children = Object.entries(builders)
      .map(
        ([k, builder]) => ''
          + k 
          + ': ' 
          + builder([...path, k])
      )
    return '{' + children.join(', ') + ' }'
  }

That's it for objects.

Wiring things up

Let's wire up our individual schema handlers:

type JsonSchema<T> =
  | { type: 'string' }
  | { type: 'array', items: T }
  | { type: 'object', properties: Record<string, T> }

const fold
  : (schema: JsonSchema<Builder>) => Builder
  = (schema) => {
    switch (schema.type) {
      case 'string':
        return cloneString
      case 'array':
        return cloneArray(schema.items)
      case 'object':
        return cloneObject(schema.properties)
    }
  }

Note that our JsonSchema type isn't recursive. Not only does this help with TypeScript IDE performance, but it also lets us accurately represent the actual type of our schema during traversal.

Note that our fold function is also not recursive. We're not recursing yet; we're still wiring things up.

If you haven't seen this pattern before, I wrote about it previously in Recursion in TypeScript (without the tears).

Making it recursive

I said this already, but it's worth reiterating: this section assumes you're familiar with the idea of a Functor.

Prerequisites

If you need to brush up, here are a few resources:

Functors, applicatives and Monads in pictures
Recursion in TypeScript, which covers the same pattern in more depth

Okay, we're finally ready to wire up our fold function.

To do that, we need 2 more components:

A JSON Schema Functor

A Functor is an “interface” from functional programming.

Data that satisfies the Functor interface has a single method, map, which takes a function, and applies the function to the element(s) inside the Functor.

If you've ever used Array.prototype.map before, then you're already familiar with the Array Functor.

Let's define a Functor for JSON Schema specs:

const Functor = {
  map<S, T>(fn: (src: S) => T) {
    return (x: JsonSchema<S>): JsonSchema<T> => {
      switch (x.type) {
        case 'string': return x
        case 'array': return {
          type: 'array',
          items: fn(x.items)
        }
        case 'object': return {
          type: 'object',
          properties: Object.fromEntries(
            Object.entries(x.properties).map(
              ([k, v]) => [k, fn(v)]
            )
          )
        }
      }
    }
  }
}

A `combine` function

To do that, we're going to write a function called combine. I call it that because it's closely related to the Y-combinator, and because the traditional name for it (catamorphism) isn't particularly accessible:

type Fold<T> = (x: JsonSchema<T>) => T

const combine
  : <T>(fold: Fold<T>) => Fold<T>
  = (fold) => function loop(value) {
    return fold(Functor.map(loop)(value))
  }

Putting it all together

Let's put it all together now:

const buildDeepClone
  = (schema: JsonSchema<any>) => Function(
    'data', 
    'return ' + combine(fold)(schema)(['data'])
  )

For ~60 lines of code (about 20 of them types), that's not bad, especially for a solution that's an order of magnitude faster than the one that ships with the platform.

Here's a sandbox if you'd like to see it working.

Fuzz testing

We're not done yet. We've tested our buildDeepClone function with a few hardcoded inputs, but that doesn't give us enough confidence to ship this as a library.

I don't know about you, but I'm lazy. I'd rather not rack my brain to think of edge cases, and my fingers hurt just thinking about typing them all out.

Not to mention, those kinds of tests are super brittle: if we change something about our implementation, we have to go and update a bunch of tests by hand, which often involves a bunch of guess-work to figure out what the tests mean.

Let's fuzz test our buildDeepClone function instead.

For that, we'll use a library called fast-check. If you're not familiar with it, now you know.

`fast-check`

fast-check is a property testing library that exposes a combinator API that will feel very familiar if you've used zod before.

You use these combinators to build up arbitraries. Arbitraries are pseudo-random data generators.

Our goal:

generate a random JSON Schema
generate a random input that satisfies the JSON Schema
pass the schema to our buildCloneDeep function to derive a deepClone function
pass the random input to our deepClone function
use vitest to make sure that the generated input and the cloned input are deeply equal to each other

Generate a random JSON Schema

First, let's write an arbitrary that generates a “random” (pseudo-random) string schema.

Generating a string schema

import * as fc from 'fast-check'

const stringSchemaArbitrary = fc.constant({
  type: 'string'
})

In this example we're using the fc.constant combinator to generate a constant value.

The reason we need to wrap this constant value in an arbitrary is so that we can compose it with other the other arbitraries we need to write.

Generating an array schema

Okay, let's build the array schema arbitrary:

import * as fc from 'fast-check'

const arraySchemaArbitrary 
  = <T>(model: fc.Arbitrary<T>) => fc.record({
    type: fc.constant('array'),
    items: model
  })

Generating an object schema

Now let's build the object schema arbitrary:

import * as fc from 'fast-check'

const objectSchemaArbitrary
  = <T>(model: fc.Arbitrary<T>) => fc.record({
    type: fc.constant('object'),
    properties: fc.dictionary(fc.string(), model)
  })

All together now

Okay, so we have our component parts. How do we compose them to generate a random JSON Schema?

For that, we'll use fc.letrec.

Using the fc.letrec API might feel familiar to you. That's because it's design is very similar to the “continuation passing” approach we used earlier to generate our stringified function bodies.

Here's what using it looks like:

import * as fc from 'fast-check'

const SchemaBuilder = fc.letrec((tie) => ({
  string: stringSchemaArbitrary,
  array: arraySchemaArbitrary(tie('*')),
  object: objectSchemaArbitrary(tie('*')),
  ["*"]: fc.oneof(
    tie('string'),
    tie('array'),
    tie('object'),
  )
}))

Using it looks like this:

import * as fc from 'fast-check'

const twoSchemas = fc.sample(SchemaBuilder['*'], 2)

console.log(JSON.stringify(twoSchemas[0], null, 2))
// => {
//   "type": "object",
//   "properties": {
//     "$C_5g$G$": { "type": "string" },
//       "G_If_1$_": { "type": "string" },
//       "ku": { "type": "string" },
//       "$_$_9_c$I": {
//         "type": "array",
//         "items": { "type": "string" }
//       },
//       "VF$_$": { "type": "string" },
//       "G": { "type": "string" }
//     }
//   }
// }

console.log(JSON.stringify(twoSchemas[1], null, 2))
// => {
//   "type": "array",
//   "items": {
//     "type": "array",
//     "items": { "type": "string" }
//   }
// }

That covers our random JSON Schema generator. What about the inputs?

Reading the schema to generate random inputs

For this, we can re-use the combine function we wrote earlier to avoid having to deal with walking the schema tree.

import * as fc from 'fast-check'

export const generateData = combine((schema) => {
  switch (schema.type) {
    case 'string': return fc.string()
    case 'array': return fc.array(schema.items)
    case 'object': return fc.record(schema.properties)
  }
})

Let's unpack that:

Our generateData function accepts a JSON Schema as input, then pattern matches on the schema's "type" property:

if schema.type === "string", we return a string arbitrary
if schema.type === "array", we return an array arbitrary, passing the arbitrary at schema.items into fc.array
if schema.type === "object", we return a record arbitrary, passing the record of arbitraries at schema.properties into fc.record

And that's it. Because combine handles the recursion for us, we're done.

Writing our test

fast-check is designed to integrate seamlessly with vitest (and if this issue gets traction, it might someday be integrated as a first-class part of the API 🤞).

Here's all we need to do to fuzz test that our buildDeepClone function works with any arbitrary JSON Schema:

import { assert, test } from 'vitest'
import * as fc from 'fast-check'

test('fuzz test', () => {
  fc.assert(
    fc.property(SchemaBuilder['*'], (schema) => {
      const [data] = fc.sample(generateData(schema))
      const deepClone = buildDeepClone(schema)
      const clone = deepClone(data)
      assert.deepEqual(clone, data)
    }), 
    { numRuns: 1000 }
  )
})

That's it! Notice that we're running the test 1,000 times. We can of course configure that – by default it runs the test 100 times.

Here's a sandbox if you'd like to run the test suite yourself.

Tip: If you run the test suite, you can scroll up in the terminal to see the generated schema, generated input, and cloned data for each run.

Closing thoughts

Hopefully this helped you see, if not the whole owl, enough that you could draw the rest if you wanted.

If you'd prefer not to write this kind of thing yourself, take a look at @traversable/schema.

We support generating deepClone, deepEqual and more for the follow schema types:

And thanks for reading! This one was pretty long. If you made it all the way through and have feedback, or just want to chat about anything we talked about, feel free to reach out via email at ahrjarrett@gmail.com.

Aside

This approach to building leaner, more localized alternatives to bulky (and often slow) APIs was inspired by, of all things, Dune.

More specifically, it was a video about the thematic role of architecture in the Dune series.

This quote, which compares the Harkonnen's design to the Fremen's, is what got me thinking about it:

The [Harkonnens], even though they're technically the most powerful and resourceful family, struggle to adapt to Arrakis' harsh conditions, and they rely mostly on imported resources.

The Fremen on the other hand have been able to develop solutions that are locally adapted approaches that are specifically designed for [their] climate.

Instead of seeking universally applicable high tech solutions, maybe we need to be looking more for nuanced locally adapted approaches.

– Dami Lee, Dune Cities: Fiction or Reality?

I think this kind of approach could be explored in our line of work more often. It seems like this is a relatively new frontier (for the JavaScript ecosystem, at least), and I'm excited to see what others come up with as we explore the space of possibilities.

That's all for now. Cheers.

How to build JavaScript's fastest “deep equals” function

andrew jarrett — Sun, 13 Jul 2025 04:37:45 +0000

This is the first article in a series. The follow-up is titled How to build JavaScript's fastest “deep clone” function.

This is a short article about how I built JavaScript's fastest "deep equals" function.

tl;dr

The implementation we'll be talking about today is:

35-65x faster than NodeJS's built-in isDeepStrictEqual
50-110x faster than Lodash.isEqual

If you're skeptical, you can run the benchmarks yourself on Bolt by clicking "Code" and typing node index.mjs in the terminal.

Before we get into the how, let's first make sure we're on the same page about the problem we're trying to solve.

What we mean when we say 2 things are the same

An equivalence relation, or "deep equals" in the parlance of the JS ecosystem, is a function that takes 2 arguments and returns a boolean indicating whether they are "the same".

By "the same", typically we mean equal by value, not equal by reference.

Example

These are equal by reference:

const value1 = { abc: 1 }
const value2 = value1

value1 === value2 // true

These are equal by value:

const value1 = { abc: 1 }
const value2 = { abc: 1 }

value1 === value2 // false

Note that value1 === value2 returns false in the second example.

The issue is that, given non-primitive operands, the === operator computes an identity rather than an equivalence.

Put differently, the === operator answers the question, "Do both pointers point to the same place in memory?" rather than "Are both values structurally the same?"

Why does it work that way?

The short answer

The short answer is that that's the spec.

The long answer

Gather round the fire, let's talk about what we mean when we say two things are the same...

The long answer is that it's complicated. To see what I mean, try typing this out in your browser's DevTools:

console.assert(0.1 + 0.2 === 0.3)

This is part of a much larger conversation about identity and sameness. And while I think this is an interesting topic, it's been covered elsewhere, so let's sidestep it for now.

What do we actually want?

What we actually want is a more relaxed definition of equality. We want to know whether 2 values are equal according to some criteria.

Example

Let's say we're working with the following data model:

import { z } from 'zod'

type Address = z.infer<typeof Address>
const Address = z.object({
  street1: z.string(),
  street2: z.optional(z.string()),
  city: z.string(),
})

How can we tell 2 addresses apart?

A "naive" solution

Arguably the easiest solution is to hand-roll our own:

const addressEquals = (x: Address, y: Address) => {
  if (x === y) return true
  if (x.street1 !== y.street1) return false
  if (x.street2 !== y.street2) return false
  if (x.city !== y.city) return false
  return true
}

Using it looks like this:

addressEquals(
  { street1: '221B Baker St', city: 'London' },
  { street1: '221B Baker St', city: 'London' }
) // => true

addressEquals(
  { street1: '221B Baker St', city: 'London' },
  { street1: '4 Privet Dr', city: 'Little Whinging' }
) // => false

Advantages

We control the implementation
We have visibility into its behavior
Great performance

Disadvantages

Tedious to write
Easy to screw up
Subject to rot: if we add a new property to our Address type, it's easy to forget to update our equals function

A "heavy-handed" solution

Another way to solve the problem is to use an off-the-shelf solution, like Lodash's isEqual function:

import isEqual from 'lodash.isEqual'

isEqual(
  { street1: '221B Baker St', city: 'London' },
  { street1: '221B Baker St', city: 'London' }
) // => true

isEqual(
  { street1: '221B Baker St', city: 'London' },
  { street1: '4 Privet Dr', city: 'Little Whinging' }
) // => false

This is useful in a pinch, but it isn't perfect. Namely, we've solved one problem by introducing a new one: isEqual comes with a performance penalty, because it has to traverse both data structures recursively to compute the result.

Do we have any other options?

Getting closer

Another thing we could do is swap out our schema library for one that lets us derive an equals function from the schema.

The effect library supports this. Let's see what that looks like:

import { Schema } from 'effect'

const Address = Schema.Struct({
  street1: Schema.String,
  street2: Schema.optionalWith(Schema.String),
  city: Schema.String,
})

// deriving an equals function from `Address`:
const addressEquals = Schema.equivalence(Address)

addressEquals(
  { street1: '221B Baker St', city: 'London' },
  { street1: '221B Baker St', city: 'London' }
) // => true

addressEquals(
  { street1: '221B Baker St', city: 'London' },
  { street1: '4 Privet Dr', city: 'Little Whinging' }
) // => false

Advantages

Better performance than isEqual
Implementations stay in sync

Disadvantages

We have to switch our schema library, which may or may not be viable
The performance is better, but only marginally so

Comparison

To recap, we have roughly 3 options, each with its own set of tradeoffs. We can:

"roll our own" — offers the best performance, but it's annoying and brittle
use an off-the-shelf solution — convenient, but comes with the worst performance profile
write our schemas using effect — this solves #1 and partially alleviates #2, but requires us to migrate to effect

Wouldn't it be great if we had a way to somehow get the performance of hand-written equals functions, without having to actually write them by hand?

Turns out, we can.

Implementing JavaScript's fastest “deep equals”

Remember our "naive" solution? Here it is again:

const Address = z.object({
  street1: z.string(),
  street2: z.optional(z.string()),
  city: z.string(),
})

const addressEquals = (x: Address, y: Address) => {
  if (x === y) return true
  if (x.street1 !== y.street1) return false
  if (x.street2 !== y.street2) return false
  if (x.city !== y.city) return false
  return true
}

As it turns out, our naive solution is also super fast. In fact, it would be almost impossible to make it faster.

Can we use our schema to generate the super fast implementation as a string?

If we could do that, we could write that implementation to disc, or use JavaScript's native Function constructor to turn the string into code.

That would look something like this:

const addressEquals = Function('x', 'y', `
  if (x === y) return true
  if (x.street1 !== y.street1) return false
  if (x.street2 !== y.street2) return false
  if (x.city !== y.city) return false
  return true
`)

If you've never seen this trick before, chances are you're probably using it already: if you use zod@4, arktype or @sinclair/typebox, they all use the same trick under the hood when validating data.

The performance increase can be dramatic — if this is your first time seeing this technique, this video by the author of arri does a great job covering why it's fast, and how it works.

So, we know what we want (to write a function that takes a zod schema, and builds up a string that will become our equals function) — but how would we go about doing that?

Introducing `@traversable/zod`

That's exactly what zx.deepEqual from @traversable/zod does.

Using it looks like this:

import { z } from 'zod'
import { zx } from '@traversable/zod'

const Address = z.object({
  street1: z.string(),
  street2: z.optional(z.string()),
  city: z.string(),
})

const addressEquals = zx.deepEqual(Address)

addressEquals(
  { street1: '221B Baker St', city: 'London' }, 
  { street1: '221B Baker St', city: 'London' }
) // => true

addressEquals(
  { street1: '221B Baker St', city: 'London' },
  { street1: '4 Privet Dr', city: 'Little Whinging' }
) // => false

That's it. You write your zod schemas as usual, and you get the fastest possible "deep equals" function for free.

If you're curious how much faster, check out the benchmarks below.

Performance comparison

zx.deepEqual performs better than every implementation I could find, in every category, on every run.

I've included links at bottom in case you'd like to dig into what the generated code looks like, the benchmarks, or the implementation.

Here are the benchmarks for addressEquals. I used fast-check to generate the inputs, and mitata as the benchmark runner.

clk: ~3.02 GHz
cpu: Apple M1 Pro
runtime: node 22.13.1 (arm64-darwin)


  Underscore ┤■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 624.51 ns
      Lodash ┤■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 735.88 ns
      NodeJS ┤■■■■■■■■■■■■■■■■■■■ 420.93 ns
 traversable ┤■■■ 77.56 ns
  FastEquals ┤■■■■ 88.68 ns
 FastIsEqual ┤■■■■■■■■■■■■■ 275.99 ns
  ReactHooks ┤■■■■■■■■■■ 215.57 ns
     JsonJoy ┤■■■■ 91.11 ns
      Effect ┤■■■■■■■■■■ 227.12 ns
zx.deepEqual ┤ 6.77 ns

summary
  zx.deepEqual
   11.45x faster than traversable
   13.1x faster than FastEquals
   13.46x faster than JsonJoy
   31.84x faster than ReactHooks
   33.54x faster than Effect
   40.76x faster than FastIsEqual
   62.17x faster than NodeJS
   92.24x faster than Underscore
   108.69x faster than Lodash

Thanks for reading!

If you enjoyed reading this, you might enjoy the follow-up, where I use the same technique to "draw the rest of the owl":

How to build JavaScript's fastest “deep clone” function

Updates

Since publishing this article, I've added support for:

The Next Generation of Branded Types in TypeScript

andrew jarrett — Fri, 20 Jun 2025 20:17:28 +0000

This post will be shorter than most, mostly because writing this has been on my todo list since I released the newtype type 11 months ago, and since it came up in the TypeScript discord yesterday.

If you're unfamiliar with branded types in TypeScript, this article is not meant to be an introduction to them -- I recommend you read Josh Goldberg's chapter on Branded Types, and then come back.

tl;dr, about a year ago I released a type called newtype, that lets you define types like this:

import type { newtype } from "any-ts"

declare namespace integer {
  const URI: unique symbol
}

interface integer extends newtype<
  number & { [integer.URI]: never }
> {}

declare const myInt: integer

const ex_01 = myInt + 2.3
// 🚫 TypeError ^^:
//    Operator '+' cannot be applied to types
//    'integer' and 'number'

// Downcast `myInt` with the unary plus operator:
const ex_02 = +myInt + 2.3
//    ^? const ex_02: number

Play with it in the TypeScript Playground

What's happening here?

The newtype type is part of a library I maintain called any-ts.

any-ts is a TypeScript library, but different than the ones you usually see.

Rather than shipping a bunch of fancy TypeScript utility types, it ships a bunch of TypeScript primitives.

One of those primitives is newtype. If you're familiar with Rust or Haskell, this version of newtype is like a poor person's newtype.

Despite that, it's much more powerful than it looks at first glance. But since this article isn't about promoting my library -- we'll skip them for now.

Suffice to say, one of the things newtype lets you do is wrap up a primitive type (like a string or number) in a TypeScript interface.

By doing that, the name you give the type "sticks".

In other words, instead of this:

type Integer = number & { [IntegerSymbol]: never }

declare let myInt: Integer
//          ^? let myInt: number & { [IntegerSymbol]: never }

...which is harder to read and leaks implementation details, you get this:

interface integer extends newtype<number> {}

declare let myInt: integer
//          ^? let myInt: integer

Notably, you can implement every "flavor" (pun intended) of branded type that Josh outlines in his chapter on Branded Types, in terms of the newtype pattern.

If you're curious and would like to learn more, I recommend:

the TypeScript discord thread from yesterday (June 19, 2025)
the release notes where I talk about some of the interesting possibilities that a type like newtype opens up

And of course if you have any questions for me, I'm totally open to chatting. I'm on GitHub, LinkedIn, and you can always reach my by email at ahrjarrett at gmail dot com.

Inductive Types in TypeScript

andrew jarrett — Fri, 16 May 2025 20:11:00 +0000

This post demonstrates a TypeScript pattern I've been experimenting with for the last year or so.

I've been calling this pattern "inductive type constraints", but perhaps a better name would be "smart constructors", since they have "correct by construction" semantics (here's a nice article about them).

"Smart constructors" definitely sounds cooler, but "inductive types" are what they're called in other typed languages, so I went with that.

Before we dig into how they work, here are a few examples of how they can be used to solve a few long-standing TypeScript issues:

`Exact`

"exact types" is historically the 2nd-most requested feature of all time
Exact ensures that a type does not have any extra properties

Here's the implementation of Exact (Playground):

type Exact<T, S> = [keyof T] extends [keyof S]
  ? [T] extends [S] ? { [K in keyof T]: T[K] } 
  : S : never

declare function exact<S, T extends Exact<T, S>>(
  x: S, 
  y: T
): T

exact({ a: 1 }, { a: 1, b: 2 })
//                         ^ 🚫 nope

If you're not sure how or why this works, keep reading -- I talk about that in the second half of this post.

`Json`

One of the oldest TypeScript issues (#187)

Here's the implementation of Json (Playground):

type Scalar = null | boolean | number | string

type Json<T> 
  = [T] extends [Scalar | undefined] ? Scalar
  : [T] extends [{ [x: number]: unknown }] ? { [K in keyof T]: Json<T[K]> }
  : never

declare function json<T extends Json<T>>(json: T): T

json('abc')                 //   ok ✅
json({} as { x?: number })  //   ok ✅
json(/abc/)                 // nope 🚫
json({ x: [new Date] })     // nope 🚫

How does it work?

In the TypeScript discord I outlined the rules that apply when defining an inductive constraint.

There are 2 rules you need to follow.

Rule #1

If you're applying a constraint to a type parameter directly, you can't distribute the parameter or you'll get a circular reference.

What does that look like in practice?

type StringLiteral<T> 
  = [T] extends [string] 
  ? string extends T ? never 
  : string 
  : never

declare function test<T extends StringLiteral<T>>(x: T): T


///////////////////////////
///    expect: OK ✅    ///
let ex_01 = test('abc')
//  ^? let ex_01: "abc"
let ex_02 = test(`abc${String()}def`)
//  ^? let ex_02: `abc${string}def`


//////////////////////////////////////
///    expect: red squiggles 🚫    ///
test(String())
test('abc' + '')

Playground

Rule #2

Instead of returning T (the type you're constraining), you need to return the least upper bound.

What does that look like in practice?

This one's a bit more subtle, so I encourage you to play around with the example in the playground to build an intuition for how it works.

In short: you can't return T itself, or T will be circular.

Instead, return the least constrained (most permissive) version of the type you're constructing.

Let's look at the StringLiteral example again:

type StringLiteral<T> 
  = [T] extends [string] 
  ? string extends T ? never 
  : string   //  <-- here
  : never

Instead of returning T, I return the constraint that I want to apply.

This will feel weird the first few times you do it. Once it clicks, though, if you're like me, you'll gain a new appreciation for one of the many subtleties of the TypeScript type system.

More examples are in the works, but that's enough for today.

Inductive types are much more powerful than they might seem at first glance. And they're important to keep in your toolbelt, especially if you're a library author.

Thanks for reading!

Recursion in TypeScript (without the tears)

andrew jarrett — Fri, 21 Mar 2025 13:50:07 +0000

Principal devs hate this one weird trick...

Have you felt frustrated by how hard recursion is?

If you've ever tried writing recursive code in TypeScript, all types do is seem to get in the way, and distract you from the real problem you're trying to solve.

Trust me, I've been there.

But what if I told you there was a way you could make TypeScript do the hard part for you?

What if there was a way to make recursion type-safe?

Today I'm going to show you a trick I wish I'd known about circa 2016, when I started on my TypeScript journey.

Enough preamble: let's look at some code.

`JSON.map`

To start, let's imagine the built-in JSON namespace had a .map method, similar to Array.

How would it behave?

For starters, it would have to be structure-preserving, like Array.prototype.map.

What do I mean by structure-preserving?

Simple: if you map over an array, the array that comes out will always have the same number of elements as the one you put in.

Same things goes for our imaginary JSON.map -- only since we also have objects, it will need to preserve the object keys, and only apply the function to object values.

To make implementing our map function easier, first let's write a function that abstracts away whether we're mapping over an array or an object, since for our purposes, we want to "forget" that there's a difference.

We'll call it mapObject, since arrays are also objects:

function mapObject(
  src: { [x: string]: unknown } | unknown[], 
  mapFn: (src: unknown, ix: any, xs: typeof src) => unknown
) {
  if (Array.isArray(src)) return src.map(mapFn)
  else {
    const keys = Object.keys(src)
    let out: { [x: string]: unknown } = {}
    for (const key of keys) {
      out[key] = mapFn(src[key], key, src)
    }
    return out
  }
}

If we try it out, we can see that it works with both objects an arrays, and that in both cases, our implementation is structure-preserving.

Now let's implement JSON.map:

type Scalar = 
  | null
  | boolean
  | number
  | string

type Json<T> =
  | Scalar
  | readonly T[]
  | { [x: string]: T }

const isScalar = (src: unknown) => src == null 
  || typeof src === 'boolean' 
  || typeof src === 'number' 
  || typeof src === 'string'

const isArray
  : <T>(src: unknown) => src is readonly T[] 
  = Array.isArray

const isObject = <T>(src: unknown): 
  src is { [x: string]: T } => !!src
  && typeof src === 'object' 
  && !isArray(src)

export function mapJSON<S, T>(
  f: (src: S) => T
): (x: Json<S>) => Json<T> {
  return (x) => {
    switch (true) {
      default: return x
      case isScalar(x): return x
      case isArray(x): return mapObject(x, f)
      case isObject(x): return mapObject(x, f)
    }
  }
}

That's a lot of code -- let's walk through it:

`Json<T>`

First I created a Json type. Only, this Json type is a little bit different than what you'll usually see; can you spot this difference?

type Scalar = 
  | null
  | boolean
  | number
  | string

type Json<T> =
  | Scalar
  | readonly T[]
  | { [x: string]: T }

Well, for starters, this definition of Json is not recursive.

To see what I mean, let's compare it to the Json type you'll usually see in the wild:

type Json =
  | Scalar
  | readonly Json[]
  | { [x: string]: Json }

This definition has its advantages, and its disadvantages.

The biggest advantage is that it definitely rules out values such as bigint, symbol, Dates and undefined.

But the disadvantage is that the type isn't flexible. It's closed, rather than open.

What we're trying to do with our JSON.map function is think about JSON in terms of its structure -- remember, we're zooming out, and focusing on implementing a JSON.map that works like Array.map.

Here, from where we're standing, we're making the decision to not focus on the details that make generic data structures like Array<T>, Map<K, V> different than JSON, and instead focus on the ways in which they can be thought of as being the same.

Taking this perspective comes with its advantages, and for our use case, we're mostly interested in 2:

because this definition does not rush to constrain its input, Json.map will be able to take JSON input, and map it to other, non-JSON targets (like bigints and Dates)
because this definition is not recursive, it perfectly describes our primary goal, which is to factor out recursion.

To see what I mean, let's practice some wishful thinking.

Wishful thinking

When it comes to recursion, what do we want?

If you said "to never have to write recursive code", you're well on your way to thinking like a functional programmer!

Let's explore that idea.

Let's pretend for a moment that JSON.stringify isn't a thing. It doesn't exist. And it's our job to implement it.

How would we go about implementing it? Is there a way to do it that doesn't involve recursion?

Let's write some pseudo-code:

function toString<T>(json: Json<T>) {
  switch (true) {
    // if we've got a scalar value, turn it into a string:
    case isScalar(json): return String(json)
    // how are we supposed to get to the values?
    case isArray(json): 
    // how are we supposed to get to the values?
    case isObject(json):
  }
}

How are we supposed to implement this, if we can't call our toString function on the elements values?

Well, what if we didn't have to?

Reframing the problem

What if, again, practicing some wishful thinking, we instead use Json<string> instead of Json<T>?

function toString(json: Json<string>) {
  switch (true) {
    // if we've got a scalar value, turn it into a string:
    case isScalar(json): return String(json)
    // how are we supposed to get to the values?
    case isArray(json): 
    // how are we supposed to get to the values?
    case isObject(json):
  }
}

See if you can handle the array and object cases, now that we've factored out the recursion.

This part is important.

I highly encourage you to try it out in the Playground.

I can talk all day about how this technique is useful, or about how the technique works, but if you don't get your hands dirty, things won't stick, and this technique probably won't make any sense.

I'll give you a few minutes to try it out.

...

Okay, how'd you do?

Here's what I came up with:

Playground

function toString(json: Json<string>): string {
  switch (true) {
    case isScalar(json): return String(json)
    case isArray(json): return '[' + json.join(', ') + ']'
    case isObject(json): return '{' + Object.entries(json).map(([k, v]) => `"${k}": ${v}`).join(', ') + '}'
    default: return json satisfies never
  }
}

Was this close to what you came up with?

If not, don't feel bad: the first time I tried this, I tried too hard. In fact, I was so used to recursion being hard, that I had a hard time accepting that such a direct approach was possible.

But wait a minute... you haven't shown us anything. We're still doing wishful thinking, remember? So far we haven't actually implemented anything.

Ah, you're right. I'm getting ahead of myself. We still haven't actually factored out the recursion. Let's do that.

Factoring out recursion

For this next part, you're going to have to trust me that you'll never have to actually write this code yourself.

By that I mean, it's possible to implement a generalized version of this function.

Again, this isn't the kind of thing you'll need to "roll yourself" every time you have a new data structure you need to work with.

Okay, with that out of the way, here's the code that takes care of the recursion for us:

function lift<T>(json: T): Json<T>
function lift<T>(json: T) { return json }

function foldJson<T>(reducer: (json: Json<T>) => T): (json: Json<T>) => T {
  return function loop(value: Json<T>): T {
    return reducer(mapJson(loop)(lift(value)))
  }
}

That's it.

I've got another article planned where I talk through exactly why and how this function works, but it's worth noting that I didn't come up with it myself -- I simply ported it from the Haskell library that first introduced this technique.

Okay, that was the sweaty part.

Does it actually work?

Seeing it in use

See for yourself:

Sandbox

Great! Let's recap:

Recap

To make working with recursive code easier, we explored a way we can "factor out" recursion.

To simplify things, we chose to focus on only JSON values, and to make things concrete, we chose just to focus on implementing a naive version of JSON.stringify.

To get there, we had to make a few decisions:

To make things type-safe, we opted for a non-traditional, non-recursive definition of Json, which looked like this:

type Json<T> = 
  | null 
  | boolean 
  | number 
  | string
  | readonly T[]
  | { [x: string]: T }

Then, we used this type to implement a utility function called mapJson that let us zoom out a bit, and apply a function to a JSON value without knowing anything about its structure in advance. Importantly, this map function preserves structure -- meaning that the value that we get out will have the same "shape" as the value we put in -- the only thing that will change are the leaf values.

That map function looked like this:

export function mapJson<S, T>(f: (src: S) => T): (x: Json<S>) => Json<T> {
  return (x) => {
    switch (true) {
      default: return x
      case isScalar(x): return x
      case isArray(x): return mapObject(x, f)
      case isObject(x): return mapObject(x, f)
    }
  }
}

We leaned on some "library code" to handle the recursive bit. I won't put that code here, because it's not important that we fully grok how that code works for us to use it.
Finally, we implemented a naive version of Json.stringify. Notably, this implementation was not recursive:

function toString(json: Json<string>): string {
  switch (true) {
    case isScalar(json): return String(json)
    case isArray(json): return '[' + json.join(', ') + ']'
    case isObject(json): return '{' + Object.entries(json).map(([k, v]) => `"${k}": ${v}`).join(', ') + '}'
    default: return json satisfies never
  }
}

The takeaway here is that because this implementation is not recursive, it's also 100% type-safe. Here, TypeScript was our friend, since when we went to implement the array and object cases, it was there to remind us that we were working with string[] and { [x: string]: string }, and not unknown[] or { [x: string]: unknown }.

Finally, we put all the pieces together, wrote a few tests, and made sure it all worked!

The full implementation + tests is available in a Sandbox that you can play with.

If you're only interested in the types, you can check out the Playground.

Phew! That's a lot for one day.

Closing thoughts

It's important when you're learning something new to balance the theory with practice -- and to not overload yourself with too much information -- so I think we should call it here.

Congratulations! If this is the first time you've ever used recursion schemes before, you're not alone -- this technique, although quite popular in the functional programming world, is virtually unheard of in the TypeScript ecosystem.

If you're hungry for more, I went ahead and included an example in the Sandbox that applied the same technique to solve a notoriously tricky recursive problem: turning a deeply nested JSON object into a flat object whose keys are the paths, and whose values are the corresponding value at that path.

I've called it Json.toPaths, since that's the name most commonly used to describe this operation in the JavaScript ecosystem.

Plugs

If you liked this kind of content, you might be interested in a library that I wrote called @traversable/schema. It's a TypeScript schema library -- kinda like a lightweight zod (faster at runtime, and scales to arbitrarily large schemas without slowing down your IDE). Recursion schemes are at the heart of its implementation -- it even includes the same Json.map we implemented earlier.

And if you're hiring TypeScript developers and liked this content, I'm in the market -- let's talk! Feel free to email me at ahrjarrett@gmail.com if you'd like a copy of my resume.

DEV Community: andrew jarrett

Do anything with a Valibot schema!

Introducing: @traversable/valibot

Introducing: @traversable/valibot

What makes @traversable/valibot different?

Off-the-shelf

ᯓ🚀 vx.check

ᯓ🚀 vx.deepClone

ᯓ🚀 vx.deepEqual

ᯓ🚀 vx.toString

ᯓ🚀 vx.toType

ᯓ🚀 vx.defaultValue ✨new!✨

ᯓ🚀 vx.makeLens ✨coming soon!✨

Roll your own

ᯓ🚀 vx.fold

Bonus: @traversable/valibot-test

Updates

adds @traversable/valibot and @traversable/valibot-test to ecosystem #1298

adds @traversable/valibot and @traversable/valibot-test to ecosystem #1298

Closing thoughts

Links

Introducing: @traversable/zod

What makes @traversable/zod different?

Off-the-shelf

ᯓ📦 zx.check

ᯓ📦 zx.deepClone

ᯓ📦 zx.deepEqual

ᯓ📦 zx.deepPartial

ᯓ📦 zx.toString

ᯓ📦 zx.toType

ᯓ📦 zx.makeLens

Roll your own

ᯓ📦 zx.fold

Closing thoughts

Links

Is your code optimized for V8's JIT compiler?

How to build JavaScript's fastest “deep clone” function

tl;dr

The problem

So what's the problem?

A “naive” solution

Benchmarking our naive solution

Consistency

Instruction count

Implementing JavaScript's fastest “deep clone”

Mapping schema to syntax

Leaf nodes

Continuation passing style (CPS)

Array nodes

Object nodes

Wiring things up

Making it recursive

Prerequisites

A JSON Schema Functor

A combine function

Putting it all together

Fuzz testing

fast-check

Generate a random JSON Schema

Generating a string schema

Generating an array schema

Generating an object schema

All together now

Reading the schema to generate random inputs

Writing our test

Closing thoughts

Aside

Links

How to build JavaScript's fastest “deep equals” function

tl;dr

What we mean when we say 2 things are the same

Example

The short answer

The long answer

What do we actually want?

Example

A "naive" solution

Advantages

Disadvantages

A "heavy-handed" solution

ᯓ🚀 `vx.check`

ᯓ🚀 `vx.deepClone`

ᯓ🚀 `vx.deepEqual`

ᯓ🚀 `vx.toString`

ᯓ🚀 `vx.toType`

ᯓ🚀 `vx.defaultValue` ✨new!✨

ᯓ🚀 `vx.makeLens` ✨coming soon!✨

ᯓ🚀 `vx.fold`

ᯓ📦 `zx.check`

ᯓ📦 `zx.deepClone`

ᯓ📦 `zx.deepEqual`

ᯓ📦 `zx.deepPartial`

ᯓ📦 `zx.toString`

ᯓ📦 `zx.toType`

ᯓ📦 `zx.makeLens`

ᯓ📦 `zx.fold`

A `combine` function

`fast-check`

Introducing `@traversable/zod`

`Exact`

`Json`

`JSON.map`

`Json<T>`