coerce.boolean incorrect

[lacherogwu]

import { z } from 'zod';

const schema = z.object({
	something: z.coerce.boolean(),
});

console.log(schema.parse({ something: 'false' }));

expected:

{ something: false }

got:

{ something: true }

[vtgn]

Hello !

No, this behavior is normal.
You convert the string "false" into a boolean, and in Javascript, any non empty string is converted into the true boolean, only the empty string "" is converted into the false boolean.

You can verify it by executing this code:

console.log(Boolean("false")); // displays true

You can do something like that:

const booleanStringSchema = z.string().transform(value => {
  if (value === "true") {
    return true;
  } else if (value === "false") {
    return false;
  } else {
    throw new Error("The string must be 'true' or 'false'");
  }
});

Regards.

[lacherogwu]

I believe it's incorrect. Coercion should convert the string into the desired type. For example, coercing a boolean string 'false' should result in false, which is the expected behavior.

[vtgn]

No, you are wrong.
This is normal that coerce method uses the standard javascript conversions rules.

Go read the documentation: https://zod.dev/?id=coercion-for-primitives
Particularly this part:

This is exactly what I explained to you.

If you find these rules illogical, go blame javascript specification writers. ;)
But if you want different conversion rules, you'll have to implement them yourself like in my previous example.

Regards.

[jameslporter]

I agree that the js spec is weird but do think one would assume coerce of string value true|false to work. Pretty common to use booleans in forms which transmit as strings but we want them to be proper booleans for the database. Transfrom didn't work for me in this use case but preprocess did like so:

const booleanStringSchema = z.preprocess(value => { if(typeof value == 'boolean') return value if (value === "true") { return true; } else if (value === "false") { return false; } else { throw new Error("The string must be 'true' or 'false'"); } },z.boolean());

The first conditional is needed because the types are checked on their way out of the database and have the boolean type.

[vtgn]

I agree that the js spec is weird but do think one would assume coerce of string value true|false to work. Pretty common to use booleans in forms which transmit as strings but we want them to be proper booleans for the database. Transfrom didn't work for me in this use case but preprocess did like so:

const booleanStringSchema = z.preprocess(value => { if(typeof value == 'boolean') return value if (value === "true") { return true; } else if (value === "false") { return false; } else { throw new Error("The string must be 'true' or 'false'"); } },z.boolean());

The first conditional is needed because the types are checked on their way out of the database and have the boolean type.

Personally, I don't find these coercions rules weird.
Bash, Python, Perl use the same rules.
The goal is to be able to convert any primary type value into a boolean value.
For numbers, 0 is false, other values are true: it is probably a choice made to be similar to the boolean values in binary (0=false, 1=true).
For strings, it is most obvious to apply a coercion rule based on the string length which applies the same rule as the numbers. Imagine if you choose that "true" string is true, and other strings values are false: it is less obvious that "false", "blabla" and empty strings have the same boolean value. Same thing if "false" is false and other values are all "true". And what about the strings in another languages? "vrai"? "faux"? Much more easy and logical to do a coercion's rule based on the strings length.

[jameslporter]

@vtgn got me thinking and I was reviewing my giant diff with other changes this am. Decided only returning a value on boolean type or string value of "true" or "false". Anything else should throw the error like this.

const booleanStringSchema = z.preprocess(value => { if(typeof value == 'boolean') return value if (value === "true") { return true; } else if (value === "false") { return false; } else { throw new Error("The string must be 'true' or 'false'"); } },z.boolean());

[jameslporter]

Also worth mentioning existing db values may be undefined. For my use case I just default it to true by adding || value === undefined to the value equal string true line. More important is an error here is an app error. You'll likely still want a validator with a nice user error message that ideally they will never encounter.

[cbovis]

Also found this confusing. Perhaps would be nice if the API let you swap between two methods of coercion (intuitive and native). Intuitively I'd expect this API to convert "false" into a false boolean since most of the time I think that's what people would require. In my example I've using Zod to parse querystring values and for a boolean I'm using true/false strings.

Something like: z.coerce.boolean(rawValue, { method: "intuitive" }).

[hunkydoryrepair]

I find this highly problematic, too. When used for parameter validation on a GET request, we only have strings. So, it will always be false because we get it from a string source. ?value=false

In order to validate that, we want the string to be a boolean. is there an option to JSON.parse prior first?

[scotttrinh]

Here's what works in this specific case, and it's unrelated to z.coerce (which by design just wraps primitive data in the constructor):

z.enum(["true", "false"]).transform((val) => val === "true");

But think about this API for a second: you probably have a very specific idea of how this conversion should work. Should ?value be parsed as true or false or throw an error? Should ?value=TrUE parse correctly? What about ?value=true&value=false? Handling these edge cases requires understanding the context here, and Zod specifically is designed to follow the platform here. If you control the clients, I'd suggest being strict and going with something like what I've outlined above, but if you're trying to handle generic URLs/form submissions, you might have to make some more complex schemas. Luckily, once you define the rules of your system, you're free to package it up as a schema and reuse it throughout your own code.

[vtgn]

I find this highly problematic, too. When used for parameter validation on a GET request, we only have strings. So, it will always be false because we get it from a string source. ?value=false

In order to validate that, we want the string to be a boolean. is there an option to JSON.parse prior first?

Personaly, I use class-validator (and class-transformer if needed) decorators to validate incoming and outgoing dtos in header and body (NestJs integrates it easily), and it manages easily the booleans. I use zod to validate the arguments of my internal db services methods, and apis.

[scotttrinh]

Going to close this discussion as "works as intended" and furthermore, the documentation specifically calls out this case and provides some guidance on what to do if the default behavior does not work for you. TL;DR: do not treat coerce as "do what I expect" any more than you should treat Boolean(value) as "do what I expect" since that's precisely what we do, and this design is intentional and consistent.

As a side note: I don't want to come off as dismissive of the pain here: parsing stringy APIs like query parameters and form data is a difficult problem and there are few tools out that that really help. Zod will probably be part of a general solution that someone will eventually build, but the behavior of Zod specifically is designed to match TypeScript's type system and JavaScript's runtime, so we inherit the quirks involved here.