[typescript-fetch] Fixed issue where unique arrays (sets) of primitive values aren't initialized properly

[davidomid]

Resolves #19520

This PR aims to fix the above bug, by ensuring that set properties from API responses are correctly initialized as sets instead of being passed directly as arrays.

Explanation of the modelGeneric.mustache change

isPrimitiveType appears to be true for arrays which contain primitives, not just for primitives themselves. Because of the template conditions, this means that arrays of primitives were being passed verbatim from the API response.

This logic is fine for regular arrays, but for sets this causes a problem, as the values aren't being converted to a Set after being retrieved from the API. This leads to issues where the client thinks the property is a Set, but it's actually an array. The outcome of this is that accessing Set members such as size won't work at runtime, but trying to access length will cause a TypeScript compilation error.

This PR aims to fix this problem by adjusting the logic in modelGeneric.mustache to correctly handle arrays of primitives which contain unique items.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.6.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[davidomid]

As it's my first time contributing to this project, I'm a bit unsure on the best way of testing this change. I think ideally it would be great if there were some assertions for validating that Set members (size, has, etc.) are actually accessible on a generated Set property, as that's the bug being fixed. After reading the docs in this repository, I'm still a bit confused about how/where a test like that is meant to be written and would really appreciate some guidance.

cc: @TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny @topce @akehir @petejohansonxo @amakhrov @davidgamero @mkusaka as the technical committee for this area.

[macjohnny]

@davidomid you can add a test of the generated typescript, running typescript code, in https://github.com/OpenAPITools/openapi-generator/blob/master/samples/client/petstore/typescript-fetch/tests/default/test/PetApi.ts

or alternatively, you can add a java test in https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/test/java/org/openapitools/codegen/typescript/fetch/TypeScriptFetchModelTest.java

but in this case, i guess its fine without writing a new test, since the generated samples are used as manual verification by human reviewers

[macjohnny]

thanks for your contribution!

the type in the interface is Set, so your change fixes that in the deserialization:

openapi-generator/samples/client/petstore/typescript-fetch/builds/default-v3.0/models/Pet.ts

Line 58 in e914c40

photoUrls: Set<string>;