Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@ssi02014
Copy link
Contributor

@ssi02014 ssi02014 commented Sep 24, 2025

Work Overview

Unifying the default value assignment logic for the mapper within the errors file and improving the any type.

as-is

export function flattenError(error: $ZodError, mapper = (issue: $ZodIssue) => issue.message) {}

export function treeifyError<T>(error: $ZodError, _mapper?: any) {
  const mapper: (issue: $ZodIssue) => any =
    _mapper ||
    function (issue: $ZodIssue) {
      return issue.message;
    };
  // ...
}

export function formatError<T>(error: $ZodError, _mapper?: any) {
  const mapper: (issue: $ZodIssue) => any =
    _mapper ||
    function (issue: $ZodIssue) {
      return issue.message;
    };
  // ...
}

to-be

export function flattenError<T, U>(error: $ZodError<T>, mapper = (issue: $ZodIssue) => issue.message as U) {}
export function treeifyError<T, U>(error: $ZodError<T>, mapper = (issue: $ZodIssue) => issue.message as U) {}
export function formatError<T, U>(error: $ZodError<T>, mapper = (issue: $ZodIssue) => issue.message as U) {}

@ssi02014 ssi02014 changed the title Unify code structure and improve types refac(errors): Unify code structure and improve types Sep 24, 2025
Comment on lines -258 to +257
const mapper: (issue: $ZodIssue) => any =
_mapper ||
function (issue: $ZodIssue) {
return issue.message;
};
export function formatError<T, U>(error: $ZodError<T>, mapper = (issue: $ZodIssue) => issue.message as U) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the flattenError function approach to unify mapper handling felt more readable, and it also allows for improvements to the any type.

@colinhacks colinhacks merged commit 02a5840 into colinhacks:main Oct 1, 2025
4 checks passed
@colinhacks
Copy link
Owner

Thanks for the the PR but I don't personally like adding type signatures to the implementation of an overloaded function. It introduces duplication and potential for drift between the overload signatures and the implementation. Feels cleaner to be to keep things as untyped as possible and use casts to indicate the

@ssi02014
Copy link
Contributor Author

ssi02014 commented Oct 2, 2025

@colinhacks
Oh, I understand. Thank you for incorporating this Pull Request despite having your preferred approach.

I would appreciate it if you could understand that the true significance of this Pull Request was actually to unify the default handling method for the mapper.

Thank you for providing such a great library. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants