-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
typescript-axios generator string property with date-time format needs to remain a string #3842
Comments
👍 Thanks for opening this issue! The team will review the labels and make any necessary changes. |
you could pass a custom type-mapping |
Thanks @macjohnny that got me to what I need, with a little trial and error it looks like the parameter to switch JS Date objects to strings is |
The funny thing is that even with |
Anyone solved this problem? I have got a lot of warnings about mapping functions |
Description
Using
typescript-axios
generator, I'm getting some undesirable behavior:For an API with a model property defined as type
string
with a format ofdate-time
, the generated interface has a type ofDate
instead ofstring
.We have serious issues with time zones when converting the strings we receive from and pass to the API to a Date object on the client that are easily avoided by keeping the values as strings.
openapi-generator version
0.0.17-4.1.1
OpenAPI declaration file content or url
Here is the full document: https://gist.github.com/wpatter6/dfe34db36300258fbabf7cbf102a0fff
Here is an example property causing the issue:
this results in
Command line used for generation
openapi-generator generate -i swagger/swagger.json -g typescript-axios -o src/api/generated -t swagger/generator-templates/
Steps to reproduce
typescript-axios
Related issues/PRs
Appears to be related to these issues:
#926
#2745
Suggest a fix/enhancement
Perhaps a CLI flag or config setting could allow defining the desired behavior of the Date fields. I'd like for it to result in
startDate?: string
orstartDate?: Date | string
would be fine as well. In any case it's probably useful to allow the consumer to be able to determine the date format string. I believe the fixes in the above issues would need type checking to prevent runtime errors as well.Thanks!
The text was updated successfully, but these errors were encountered: