typegen does not follow referenced parameters

[nils4cosee]

First of all, thank you for this project. Out of all the projects I have seen so far, this is the one that suites us best and we are currently trying to use it in our project.

My current problem is that typegen does not resolve $ref-objects that are parameters.

Example input:

openapi: "3.0.0"
info:
  title: ParamRefExample
  version: 1.0.0
paths:
  "/endpoint/{id}/one":
    get:
      operationId: operationOne
      parameters:
        - $ref: "#/components/parameters/Id"
      responses:
        200:
          description: Success
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Response'
  "/endpoint/{id}/two":
    get:
      operationId: operationTwo
      parameters:
        - $ref: "#/components/parameters/Id"
      responses:
        200:
          description: Success
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Response'
components:
  parameters:
    Id:
      name: id
      required: true
      in: path
      schema:
        type: string
  schemas:
    Response:
      type: object
      properties:
        success:
          type: string

Notice the UnknownParamsObject in the the output of typegen.

import {
  OpenAPIClient,
  Parameters,
  UnknownParamsObject,
  OperationResponse,
  AxiosRequestConfig,
} from 'openapi-client-axios'; 

declare namespace Components {
  namespace Parameters {
    namespace Id {
      export type Id = string;
    }
  }
  namespace Schemas {
    export interface Response {
      success?: string;
    }
  }
}
declare namespace Paths {
  namespace OperationOne {
    namespace Responses {
      export type $200 = Components.Schemas.Response;
    }
  }
  namespace OperationTwo {
    namespace Responses {
      export type $200 = Components.Schemas.Response;
    }
  }
}

export interface OperationMethods {
  /**
   * operationOne
   */
  'operationOne'(
    parameters?: Parameters<UnknownParamsObject>,
    data?: any,
    config?: AxiosRequestConfig  
  ): OperationResponse<Paths.OperationOne.Responses.$200>
  /**
   * operationTwo
   */
  'operationTwo'(
    parameters?: Parameters<UnknownParamsObject>,
    data?: any,
    config?: AxiosRequestConfig  
  ): OperationResponse<Paths.OperationTwo.Responses.$200>
}

export interface PathsDictionary {
  ['/endpoint/{id}/one']: {
    /**
     * operationOne
     */
    'get'(
      parameters?: Parameters<UnknownParamsObject>,
      data?: any,
      config?: AxiosRequestConfig  
    ): OperationResponse<Paths.OperationOne.Responses.$200>
  }
  ['/endpoint/{id}/two']: {
    /**
     * operationTwo
     */
    'get'(
      parameters?: Parameters<UnknownParamsObject>,
      data?: any,
      config?: AxiosRequestConfig  
    ): OperationResponse<Paths.OperationTwo.Responses.$200>
  }
}

export type Client = OpenAPIClient<OperationMethods, PathsDictionary>

I guess I will look for a workaround in the short term, but it would be great if this was fixed.

[nknapp]

The workaround is to preprocess the openapi-spec using the json-refs package. I use its filter-option to exclude references to #/components/schema from being resolved.

[npdev453]

@anttiviljami

related bug in dtsgenerator was fixed in v3.12.1

But I know that we use custom modification of dtsgenerator v2, so can you try to update that fork?

[ruaanvds]

Testing with ^7.1.3 this appears to still be an issue. I can confirm that @nknapp's solution works as expected, although it'd be ideal if this step wasn't required.

Something like this works:

"generate": "json-refs resolve openapi.spec.yaml > openapi.spec.resolved.yaml && typegen openapi.spec.resolved.yaml > ./src/shared/client/index.ts"

[nils4cosee]

@ruaanvds This is a great library and it has helped us a lot in the past. But since this issue, I went with oazapfts instead. I also wrote a small blog post about it.

[morzhan]

dear @nils4cosee, this workaround was great! this package handles it as of >=7.4.0 correctly.

[anttiviljami]

This is fixed as of [email protected]