Skip to content

Feature request: optional flag to type a field as Date for date-time or date formats #544

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
josh-feldman opened this issue Mar 30, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@josh-feldman
Copy link

I am working on a project using OpenAPI v3 and the schema contains objects which use the type string with the format date-time.

example:

SomethingWithATimestamp:
  title: SomethingWithATimestamp
  type: object
  properties:
    timestamp:
      type: string
      format: date-time
      example: "2021-03-29T17:18:30.966Z"

The Typescript output generated by openapi-typescript results in type string (as intended). But in our case having it parsed as Date would save us a lot of manual unwrapping and .toISOString() calls, as JSON.stringify will convert the dates to ISO strings for us after calling res.send().

Therefore, an optional flag to enable parsing strings with the date-time or date format as Date would be very helpful!

@josh-feldman josh-feldman changed the title Feature request: optional flag to type a field as date for data-time or date formats Feature request: optional flag to type a field as Date for data-time or date formats Mar 30, 2021
@josh-feldman josh-feldman changed the title Feature request: optional flag to type a field as Date for data-time or date formats Feature request: optional flag to type a field as Date for date-time or date formats Mar 30, 2021
@josh-feldman
Copy link
Author

It would be additionally helpful if you could specify where you want the changes to occur. For example, perhaps you want incoming data like query params to stay string, but the ability to type response body fields as Date

@drwpow drwpow added the enhancement New feature or request label Apr 5, 2021
@drwpow
Copy link
Contributor

drwpow commented Apr 5, 2021

I could see something like this being generally-useful. What do you think about a Node.js-only API, that allows you to override the types per-object? Something like:

openapiTS(mySchema, {
  // other options
  formatter((schemaObj) => {
    if (schemaObj.format === 'date-time') {
      return 'Date'; // the TypeScript “Date” type, as a string
    }
    // for all other schema objects, let openapi-typescript decide (return undefined)
  })
});

This is something that I would want the schema authors to control, so that they can manage it. Because even in your scenario, I’d argue that string is “correct” because that’s what the API is actually returning, but I can see how the ability to override it in scenarios would be helpful.

@josh-feldman
Copy link
Author

I think that sounds like a highly flexible solution and gives users of the package a lot more control in plenty of edge-cases, mine included.

@drwpow drwpow mentioned this issue Apr 15, 2021
@drwpow
Copy link
Contributor

drwpow commented Apr 15, 2021

Just added this at openapi-typescript@next. Also added some docs to the README. Please give it a try and see if it’s working as expected! Happy to get feedback on this before it goes out in the next release.

@drwpow
Copy link
Contributor

drwpow commented Apr 15, 2021

Also as an aside, please see the comment here regarding the Node.js API. The Node.js API may change to being an async-only function. But the advantage is it could fetch & parse remote schemas. Please leave a comment there if you have thoughts on that (we could even make it be a breaking 4.0 change if desired).

@drwpow drwpow closed this as completed May 19, 2021
@esoteloferry
Copy link

Hi @drwpow , thanks for your work : )
I have a question, can I still use custom formatter in latest openapi-fetch (0.8.2) , I receive a string type: date in frontend and want to convert string to date .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants