Skip to content

feat: display valid enum values for "isEnum" errors #887

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

hood
Copy link

@hood hood commented Jan 28, 2021

Description

This PR changes the error message for @IsEnum() decorator to include possible options.

Checklist

  • the pull request title describes what this PR does (not a vague title like Update index.md)
  • the pull request targets the default branch of the repository (develop)
  • the code follows the established code style of the repository
    • npm run prettier:check passes
    • npm run lint:check passes
  • tests are added for the changes I made (if any source code was modified)
  • documentation added or updated
  • I have run the project locally and verified that there are no errors

Fixes

references #837

@hood
Copy link
Author

hood commented Aug 9, 2021

Is this ever gonna be merged?

@hood
Copy link
Author

hood commented Apr 14, 2022

Is this ever going to be merged?

@ozburo
Copy link

ozburo commented May 6, 2022

Yes, please merge so we don't have to create custom error messages just to show possible enum values xD

*/
export function validEnumValues(entity: any): any[] {
return Object.entries(entity)
.filter(entry => !parseInt(entry[0]))
Copy link

Choose a reason for hiding this comment

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

Implicitly defined enums actually start with 0 and due to type coercion this check is not reliable.

If you define

  enum MyEnum {
    First,
    Second,
  }

one of the entries is ['0', 'First'], and !parseInt('0') === !0 === true
and the return value for MyEnum will be ['First', '0', 1'] instead of the expected ['0', '1'].

It would be more reliable to check whether the key is not a number after all, like:

Suggested change
.filter(entry => !parseInt(entry[0]))
.filter(entry => isNaN(parseInt(entry[0])))

@NoNameProvided NoNameProvided added the status: superset by another Issue or task being tracked/handled in a different issue. label Dec 3, 2022
@NoNameProvided
Copy link
Member

Superset by #1826.

@github-actions
Copy link

github-actions bot commented Jan 3, 2023

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: superset by another Issue or task being tracked/handled in a different issue.
Development

Successfully merging this pull request may close these issues.

4 participants