Throwing errors in preprocess

Hi there,

I’m trying to implement string coercion using z.preprocess, but there seems to be no way to indicate coercion errors:

export const Str = z.preprocess((value) => {
  switch (typeof value) {
    case 'bigint':
    case 'boolean':
    case 'number':
      return value.toString();

    case 'object':
      if (value == null) {
        return value;
      }
      if (value instanceof Date) {
        return value.toISOString();
      }
      throw new Error('Could not interpret value as string');

    case 'string':
      return value.trim();

    case 'undefined':
      return value;

    default:
      throw new Error('Could not interpret value as string');
  }
}, z.string());

Str.parse([]); // Error: Could not interpret value as string (rather than a ZodError)

I tried to create verbose workarounds but none ended up working. Thanks!

Kind regards, Hampus Kraft.

[colinhacks]

Perhaps you should be able to add issues inside preprocess similar to superRefine. I’ll look into this. It would save you from having to call coerceString twice.

[morgs32]

Well @selimb this would not break from the idea that a transform would ONLY operate on valid data that has been “refined” before it. The feature here is that as you transform it into new data you can catch new errors that PREVENT transform. Put another way - the data might be INVALID in that it CANNOT be transformed correctly.

Let’s consider this note from the README on .transform():

⚠️ Transform functions must not throw. Make sure to use refinements before the transform to make sure the input can be parsed by the transform.

What if you are doing a transform that might not work? We shouldn’t have to look far for a transform that might NOT work.

For example, from the README on async-transforms:

const IdToUser = z
  .string()
  .uuid()
  .transform(async (id) => {
    return await getUserById(id);
  })

If you wrote this - hopefully your PR reviewer says, “what if getUserById doesn’t work?” Your answer cannot be, “well .transform must assume it operates on valid data”. So I guess we should update the README code snippet:

const IdToUser = z
  .string()
  .uuid()
  .transform(async (id) => {
    return await getUserById(id)
       .catch(e => {
          logger.log('Who would have guessed this person could not be found')
          // zod say you can't throw an error in a transform
          return null
       })
  })
  .refine(v => v, {
     message: 'See that transform above, must be that getUserById did not find our user',
  })

You know what else smells? You don’t have access to id in your message. Isn’t that a shame? Here’s a playground: https://runkit.com/morgs32/zod-transform

Thoughts?? @colinhacks whaddya think?