[BUG][typescript-axios] Generated JavaScript Sets are not serialized/deserialized

[BernhardPosselt]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The following schema generates a JavaScript Set property:

{
  "Test": {
    "required": [
      "a"
    ],
    "type": "object",
    "properties": {
      "a": {
        "uniqueItems": true,
        "type": "array",
        "items": {
          "type": "string"
        }
      }
    }
  }
}

Generated object:

export interface Test {
    /**
     * 
     * @type {Set<string>}
     * @memberof Test
     */
    'a': Set<string>;
}

However when sending this request to the server, the value is not de-serialized as an array but just replaced with an empty object ("a":{}).

Similarly, when inspecting the returned data from an API, the actual values on the JavaScript object are not wrapped in a set, but return as an array.

openapi-generator version

4.5.0

Suggest a fix

Either don't generate Set and use a T[] or add conversions for sending and receiving sets

[NoUsername]

I ran into the same issue.

As a workaround, as suggested here: #8258 (comment)

adding this typemapping fixed it for me:

(gradle kotlin dsl)

typeMappings.set(mapOf(
          // workaround for missing set serialization
          "set" to "Array"
        ))

[JulienDeBerlin]

I'm running into the same problem. We use the typescript-axios generator from OpenAPI Generator (maven Plugin - v. 6.6.0).
For a property like this in the openapi schema:

"catalogueTitles": {
            "uniqueItems": true,
            "type": "array",
            "items": {
              "type": "string"
            }
          }

in the process of the typescript code generation, we get

   /**
     * 
     * @type {Set<string>}
     * @memberof IsikResource
     */
    'catalogueTitles': Set<string>;

when using the generated client to send the object to the backend (SpringBoot Server) it results into a json with an empty object instead of an array:
catalogueTitles: {}

As a result our springboot controller can not handle the request.
I don't know how to handle this situation. The workarround proposed here seems to be kotlin based and it doesn't helps us.

Is a fix of this bug planned?

[BernhardPosselt]

@JulienDeBerlin the quick fix is to just cast your stuff to an array/set in TypeScript.

[JulienDeBerlin]

Hi @BernhardPosselt, i guess I could convert the set into an array and then write my own axios client that accepts this customed object as param. But the all idea of using openapi was for us to use the generated DTOs and clients.

[BernhardPosselt]

You always want a wrapper around the generated client because the generated client will inevitably change when you upgrade the lib. The wrapper around it will allow you to change behavior in one place and not in multiple locations. So put those casts there ;)

[JulienDeBerlin]

Actually i already use a wrapper arround the client because it was the only way i found to customize the basePath. But in that case, i'm not sure how it can help me.

For instance this is one of methods in the generated client:

   /**
     * 
     * @param {SaveResourcesParams} saveResourcesParams 
     * @param {*} [options] Override http request option.
     * @throws {RequiredError}
     * @memberof TestManagementApiImplApi
     */
    public saveResource(resource: Resource, options?: AxiosRequestConfig) {
        return TestManagementApiImplApiFp(this.configuration).saveResource(resource, options).then((request) => request(this.axios, this.basePath));
    }

The expected param is of type Resource (generated based on the openapi description):

export interface Resource {

  /**
    * 
    * @type {string}
    * @memberof Resource
    */
   'name': string;
   /**
    * 
    * @type {string}
    * @memberof Resource
    */
   'description'?: string;   
    /**
    * 
    * @type {Set<string>}
    * @memberof Resource
    */
   'catalogueTitles': Set<string>;

}
So yes i could have an alternative method in my wrapper, that accepts a CustomedResource with a
'catalogueTitles': Array<string>;

but in that case I wouldn't use the generated method at all. May be I'm missing the point.

[BernhardPosselt]

use

saveResource({
    // other stuff here
    catalogTitles: ['a', 'b'] as unknown as Set<string>,
})

[JulienDeBerlin]

Got it, it's all about to silence TypeScript's type-checking. It works and was a great help. Thanks.

[adrianhelvikspond]

This PR fixes the serialization problem: #17790

[adrianhelvikspond]

If you want a quick and dirty(!) hack that can break with any change to the generator, you can add this after generating the client:

# HACK: Will be solved by https://github.com/OpenAPITools/openapi-generator/pull/17790/files
(
    cd "YOUR_OUTPUT_DIRECTORY"

    convert_maps_and_sets='(function convertMapsAndSetsToPlain(value: any): any {if (typeof value !== "object" || !value) {return value;} if (value instanceof Set) { return Array.from(value).map(item => convertMapsAndSetsToPlain(item)); } if (value instanceof Map) { return Object.fromEntries([...value.entries()].map(([k, v]) => [k, convertMapsAndSetsToPlain(v)])); } if (Array.isArray(value)) { return value.map(it => convertMapsAndSetsToPlain(it)); } return Object.fromEntries(Object.entries(value) .map(([k, v]) => [k, convertMapsAndSetsToPlain(v)])); })'

    for f in `find . -name '*.ts' -type f`; do
        if cat "$f" | grep -q 'convertMapsAndSets'; then
            continue
        fi
        sed -i '' -e "s/JSON.stringify(\(.*\))$/JSON.stringify(${convert_maps_and_sets}(\1))/g" "$f"
    done
)