Openapi-generator: [REQ][Typescript-Axios] string format date should be Date params and not String

[blackdev1l]

Is your feature request related to a problem? Please describe.

given the example:

    openapi: 3.0.0
    info:
      title: Sample API
      description: Optional multiline or single-line description in [CommonMark](http://commonmark.org/help/) or HTML.
      version: 0.1.9
    servers:
      - url: http://api.example.com/v1
        description: Optional server description, e.g. Main (production) server
      - url: http://staging-api.example.com
        description: Optional server description, e.g. Internal staging server for testing
    paths:
      /users:
        get:
          summary: Returns a list of users.
          description: Optional extended description in CommonMark or HTML.
          parameters:
          - name: day
            in: query
            required: true
            description: Parameter description in CommonMark or HTML.
            schema:
              type : string
              format: date
          responses:
            '200':    # status code
              description: A JSON array of user names
              content:
                application/json:
                  schema: 
                    type: array
                    items: 
                      type: string

when i generate a typescript-axios client, the method userGet method created is this:

export class DefaultApi extends BaseAPI {
    /**
     * Optional extended description in CommonMark or HTML.
     * @summary Returns a list of users.
     * @param {string} day Parameter description in CommonMark or HTML.
     * @param {*} [options] Override http request option.
     * @throws {RequiredError}
     * @memberof DefaultApi
     */
    public usersGet(day: string, options?: any) {
        return DefaultApiFp(this.configuration).usersGet(day, options)(this.axios, this.basePath);
    }

it should be day: Date instead of day: string, if i generate the client using format: date-time i got the expected behavior:

    public usersGet(day: Date, options?: any) {
        return DefaultApiFp(this.configuration).usersGet(day, options)(this.axios, this.basePath);
    }

Describe the solution you'd like

I think it should be easy to improve this part and be retrocompatible with the existing method generation using function overloading provided by typescript, the code generated seems to be already on the right path:

        usersGet(day: string, options: any = {}): RequestArgs {
            // verify required parameter 'day' is not null or undefined
            if (day === null || day === undefined) {
                throw new RequiredError('day','Required parameter day was null or undefined when calling usersGet.');
            }
            const localVarPath = `/users`;
            const localVarUrlObj = globalImportUrl.parse(localVarPath, true);
            let baseOptions;
            if (configuration) {
                baseOptions = configuration.baseOptions;
            }
            const localVarRequestOptions = { method: 'GET', ...baseOptions, ...options};
            const localVarHeaderParameter = {} as any;
            const localVarQueryParameter = {} as any;

            if (day !== undefined) {
                localVarQueryParameter['day'] = (day as any instanceof Date) ?
                    (day as any).toISOString().substr(0,10) :
                    day;
            }



            localVarUrlObj.query = {...localVarUrlObj.query, ...localVarQueryParameter, ...options.query};
            // fix override query string Detail: https://stackoverflow.com/a/7517673/1077943
            delete localVarUrlObj.search;
            localVarRequestOptions.headers = {...localVarHeaderParameter, ...options.headers};

            return {
                url: globalImportUrl.format(localVarUrlObj),
                options: localVarRequestOptions,
            };
        },

Describe alternatives you've considered

No alternatives, i'm pretty convinced that format: date and format: date-time should be of the same type: Date.

Additional context

I could work on it, maybe i will need some help figuring things out, but before to proceed i would like to know if it is the right way to do it and if it will be accepted as improvement

anyway, happy new year and thank you for this wonderfoul project! 🎉 ☃️

[blackdev1l]

paging @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11)

[macjohnny]

you can use a type-mapping to achieve your customization, see https://openapi-generator.tech/docs/usage#type-mappings-and-import-mappings

using string for format: date makes sense, because Date contains additional time information. this is also used in other typescript generators

[johnthagen]

@macjohnny Would you be able to provide an example of how to use --type-mappings to map "format": "date-time" to Date objects in typescript-axois? I can't seem to figure out how to do it without converting all string to Date.

[macjohnny]

@johnthagen see e.g. https://github.com/OpenAPITools/openapi-generator/pull/5314#issuecomment-592439151

[johnthagen]

Sorry I should have been more clear.

This property:

                "datetime": {
                    "type": "string", 
                    "description": "Time", 
                    "format": "date-time"
                }, 

Is outputting:

  /**
   * Time
   * @type {string}
   * @memberof Message
   */
  datetime: string;

# Version 4.3.1
$ openapi-generator generate \
    --input-spec http://localhost:5000/swagger.json --output src/api \ 
    --generator-name typescript-axios

But I would expect Date type for the datetime property, but string type is generated.

[macjohnny]

yes, for generators not implementing a deserialization logic, string is the correct type for format: date-time

[gm4git]

@johnthagen have you find a way to generate Date objects for strings with date-time formats? I tried adding --type-mappings=DateTime=Date but it didn't work. I'm using v4.3.1

[johnthagen]

No, I needed to do the serialization outside the generated class. It seems like that is the only option as far as I could tell.