Handling of 'readonly' and 'Readonly<>'

[RopoMen]

Bug description

Why ts-to-zod is not adding .readonly() for attributes or objects? I noticed that tests are now expecting that it fallbacks to the default type, why so?

Is there some issues with readonly? Zod objects themselves seems to make it trivial to use.

Input

Case 1

type Settings = {
  readonly foo: string
}

Case 2

type Settings = Readonly<{
  foo: string
}>

Expected output

Case 1

const testSettingsSchema = z.object({
    foo: z.string().readonly()
});

Case 2

const testSettingsSchema = z.object({
    foo: z.string().readonly() // not sure if this is needed because object has .readonly()
}).readonly();

Actual output

Case 1

const testSettingsSchema = z.object({
    foo: z.string()
});

Case 2

const testSettingsSchema = z.object({
    foo: z.string()
});

[RopoMen]

Only references into "readonly" in ts-to-zod codebase

• Implementation:

  ts-to-zod/src/core/generateZodSchema.ts

  Line 336 in 7c0835b

  if (identifierName === "Readonly" && typeNode.typeArguments) {

• Test:

  ts-to-zod/src/core/generateZodSchema.test.ts

  Line 333 in 7c0835b

  it("should fallback on the original type for Readonly<T>", () => {

[schiller-manuel]

zod's readonly support was added in August 2023 (see https://github.com/colinhacks/zod/releases/tag/v3.22.0) while the code you found is from 2021, so that probably explains why 😄

I looked at a few variations with z.infer:

I also found this zod issue: colinhacks/zod#2732

So it looks like we cannot (yet?) generate a schema that correctly represents the typescript type.

[RopoMen]

It definitely explains :)

I also noticed that issue with single property case. I was thinking that could that readonly() (Object.freeze() I think) applied to object properties which are wrapped using Readonly<>?

I would think that any improvement into this is good, even if that cannot be implemented fully until zod fixes its issues.