-
Notifications
You must be signed in to change notification settings - Fork 474
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
Reasoning for always setting defaultNumberType #1613
Labels
Comments
Hello there Marcelo00 👋 Thank you for opening your very first issue in this project. We will try to get back to you as soon as we can.👀 |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorting
I'm submitting a ...
I confirm that I
Expected Behavior
If you have the following property in an interface
I would expect TSOA to not add a format option to the corresponding type in the
openapi.yaml
:Additionally, I do not have the optional
defaultNumberType
config set in my TSOA config.Current Behavior
This is the result I will get:
The source of this behavior comes from lines 148-150 in
packages/cli/src/cli.ts
- see this pull request. If you not setdefaultNumberType
, it will just assume a double type for thenumberType
. In this context I wanted to get some clarification on why this behavior is the default approach?For our use case, we would like to just have the type without the optional format. In downstream tasks it would lead to some confusion in the validation as the input
0
will be validated against the type double in the current default behavior. For languages like Python, it would lead to an error with such an input because the0
is an integer. Removingformat: double
would lead to a successful validation as only number consists of floating numbers and integers.Possible Solution
Remove the respective lines.
Steps to Reproduce
Context (Environment)
Version of the library: 6.2.0
Version of NodeJS: 18.18.0
Detailed Description
Breaking change?
The text was updated successfully, but these errors were encountered: