Why did the default change to non-strict objects? Any hints for making a strict-object person's life easier?

[cakoose]

I just found out Zod v2/v3 ignores unknown object fields by default.

For someone who wants more strictness everywhere:

1. Does anybody else worry about forgetting to call .strict(...) every time? Is there an easy way to have ESLint catch the mistake?
2. What about adding a z.strictObject helper, just to make things a little easier to read?

I'm also curious why the default changed to non-strict. Strictness by default was actually one of my requirements when I was deciding between validation libraries a year ago :-\

[colinhacks]

Previously (in Zod 1) "nonstrict" meant that unrecognized keys were simply passed through to the output. To be clear, this isn't the current default behavior. By default, unrecognized keys get stripped out. Just want to make sure that's clear. I changed this because people were tired of putting .nonstrict() everywhere...as I'm sure you can relate.

Just added z.strictObject in alpha.9 — good idea 👍

[cakoose]

Thanks!

One thing I've been thinking about recently is that strict/non-strict parsing is often based on the context, not on the schema itself.

For example, imagine an object schema that is used in an HTTP+JSON-based API. Typically, the server is allowed to send new fields, but the client is not. It could be nice to allow both sides to use the same Zod schema, but pass in strict: true or strict: false when parsing. (Haven't thought through all the implications of this yet...)

[colinhacks]

I understand that impulse but in general I'm very anti-context. I think the behavior of parse should be entirely determined by the schema structure, it makes everything far easier to reason about. Having the two versions of this schema is so much more straightforward and explicit imo.