[typescript-fetch] (4.0.X) unioned types incorrectly deserialized

[someone1]

Description

The generated deserializer for unioned types incorrectly inlines the unioned types

openapi-generator version

openapi-generator-cli-4.0.0-20181126.024631-44

OpenAPI declaration file content or url

swagger: "2.0"
info:
  title: "Simple Test"

paths:
  "/get/Simple":
    get:
      summary: Retrieve List of Simple
      operationId: "get.Simple"
      responses:
        200:
          description: OK
          schema:
            allOf:
              - type: object
                properties:
                  items:
                    type: array
                    items:
                      $ref: "#/definitions/Simple"
              - $ref: "#/definitions/Paging"
definitions:         
  Simple:
    type: object
    required:
      - Name
    properties:
      Date:
        type: string
        format: date
  Paging:
    properties:
      more:
        type: boolean
      cursor:
        type: string

Generated Code (excerpt):

export interface InlineResponse200 {
    /**
     * 
     * @type {Paging}
     * @memberof InlineResponse200
     */
    paging?: Paging;
    /**
     * 
     * @type {Array<Simple>}
     * @memberof InlineResponse200
     */
    items?: Array<Simple>;
}

export function InlineResponse200FromJSON(json: any): InlineResponse200 {
    return {
        'paging': !exists(json, 'Paging') ? undefined : PagingFromJSON(json['Paging']),
        'items': !exists(json, 'items') ? undefined : (json['items'] as Array<any>).map(SimpleFromJSON),
    };
}

Example response (notice no "Paging" key):

{
  "items": [
    {
      "Date": "2018-11-27"
    }
  ],
  "more": true,
  "cursor": "string"
}

Command line used for generation

openapi-generator generate -i openapi.yaml -l typescript-fetch -c es6.json -o ./typescript-api/

Steps to reproduce

1. Use the provided yaml excerpt above to generate a client with the provided command line
2. Buggy code generated

Related issues/PRs

PR #569

Suggest a fix/enhancement

Not sure - the debugModels output makes it look like the generated code is accurate, there is something automatically creating a nested key for the composed model which should have its properties extend the model as it is not named.

Any ideas on how to tackle this? It almost appears as if the models passed to the template is incorrect (adding a named var Paging instead of its properties).

cc @Place1

[someone1]

Related to #1360 though my spec is v2 not v3, looks like the code is shared between the two anyway. It appears the PR is still missing support for allOf compositions.

Also, this issue is in reference to the 4.0.x branch so I think this is a dupe of many other issues that reference the 3.x version of the tool, but not the 4.0.x version. Feel free to close if you think existing issues/PRs are sufficient.

[someone1]

Pinging for ideas here - this is still an issue with the latest nightly

[prananta]

@someone1 did you solve this? I'm hitting this bug now. I think the bug is when using allOf in inline response. If I defined the response in definitions, the generated model is correct.

Version: 4.3.0
OS: macOS Catalina

[someone1]

I have a script to generate the output, make some changes to the package.json (e.g. using esnext) and run this oneliner - though to be fair it's been some months since I last had to run this as I've mostly shifted to a new project and opted to use gRPC + OpenAPI extensions instead:

find ./src/models -type f -exec sed -i -e 's/!exists.\+PagingFromJSON.\+,/PagingFromJSON(json),/g' {} \; \

[spacether]

One solution may be to add type: object definition to the Paging component
Paging is an any type schema with an (object) properties constraint which is probably not generally supported by our tooling