Zod to typebox migration advice

[alexd6631]

Hello,

I am considering moving from zod to typebox. My main motivations are the native JSON schema support and recursive
schema definition (I had to encode a tree structure, and generate a JSON schema for a yaml config file, and zod shown
its limit here).

I know the two libraries, while looking similar on the surface, have different design tradeoffs. I am looking for advice
on the best practices to mitigate the differences, or feedback from someone who has made the move from zod before. My
main usages of zod, is to act as a boundary between my core, type-safe, logic and the external world (being it
configuration files, payload validation, external API calls to services, etc ...)

One thing I really liked about Zod is the functional "Parse, don't validate" approach, and I am having a hard time going
back to the classical "validate" mindset.

While the native JSON schema approach will always lean on the validate approach, I was hoping Value.Decode and
Transform would be similar in behavior to zod parse method, but after a few tries, there are a few differences that
are putting me off :

• By default, Value.Decode on a Type.Object will not strip additional properties, while
  z.object({...}).parse(data) will result in a new, clean object. I know this has been discussed before, and
  the advice is to fix the data on the sender side, but I still find it convenient from some use cases. For instance let's
  imagine I am parsing a large API response, or a CSV file in which I am only interested in a few fields, the ability to
  parse and strip in one step, is really convenient. There is no explicitly way to enable this, but it seems feasible by
  using ajv directly.
• Value.Decode does not fill default values. With zod, if I am adding a new property to an existing schema and provide a
  default value, for retro compatibility reason, I can easily do it with the .default(val) method. Typebox seems to
  support a default option in schema, but it does not seem to honor it with Value.Decode, which I find misleading.

For default values, I tried the following workaround, but it did not work since transform are not applied when the field
data is not provided

function Default<I extends TSchema>(schema: I, value: I['static']) {
    return Type.Transform(Type.Optional(schema))
        .Decode((v) => v ?? value)
        .Encode((v) => v);
}

I am considering reimplementing a parse equivalent, using a custom ajv configuration to strip excess properties and
add defaults, followed by Value.Decode to apply transforms if necessary. But it feels a bit convoluted and I am
wondering if something similar was not already implemented by typebox users or in a 3rd party library ?

[pauldvu]

Hey @alexd6631 I'm the middle of migrating from zod to TypeBox and I'm still getting the hang of things

I agree the behaviors of parse in zod are great, I especially like zod's built in transform and pipe.

I was looking at the Value methods and I'm going to take a guess and say they were designed in such a way that we can create our own version of parse. I only had a few minutes to whip up a first pass and here is what I got for stripping as well as adding in default properties.

import { TSchema, Type as t } from "@sinclair/typebox";
import { Value } from "@sinclair/typebox/value";

const TbModel = t.Object({
  id: t.Number({ default: 123 }),
  message: t.String({ default: "hello world" }),
});
const { Diff, Create, Patch, Decode } = Value;
const Default = Create(TbModel);

const parse = <T extends TSchema>(model: T, value: Record<string, any>) => {
  const edits = Diff(value, Default).filter((v) => v.type === "insert");
  //we can strip by filtering on v.type ==="delete"
  return Decode(model, Patch(value, edits));
};
describe("First iteration of a typebox parse using Value methods", () => {
  test(" Parse empty object and return default values", () => {
    const result = parse(TbModel, {});
    expect(result.message).toBe("hello world");
    expect(result.id).toBe(123);
  });
  test("Add in missing default values", () => {
    const result = parse(TbModel, { message: "foo" });
    expect(result?.id).toBeNumber();
    expect(result?.message).toBeString();
    expect(result.id).toBe(123);
    expect(result.message).toBe("foo");
  });
});

[alexd6631]

Hello @pauldvu,

Thanks for your feedback, good idea to combine Create/Diff/Patch/Decode to reproduce parse behavior, although I think it may be less efficient than having a dedicated Parse method, it seems to come very close to the desired behavior.

I didn't have time to dig, but I would also like to try an alternative approach with ajv, which seems to support default values, and stripping with specific flag.

Let me known, if you are able to further iterate on your first pass.