Common Parameters for Various Paths Different API paths not resolved correctly

[maapteh]

Good day @horiuchi at the moment im stuck when the dtsgenerator resolves common path parameters using v3.13.2 and also v3.15.0 (latest).

So when in open-api spec the endpoint says:

"parameters": [
  { "$ref": "#/components/parameters/languageCode" },
  { "$ref": "#/components/parameters/storeId" },
]

The generator will endup with:

export type $0 = ProductsRaw.Parameters.LanguageCode;
export type $1 = ProductsRaw.Parameters.StoreId;

While i expected the name of the referenced item as a key, so i would expect:

export type languageCode = ProductsRaw.Parameters.LanguageCode;
export type storeId = ProductsRaw.Parameters.StoreId;

Do you perhaps know what can be the rootcause? Because also in your test i noticed it is not resolving the name:

https://github.com/horiuchi/dtsgenerator/blob/master/test/simple_schema_test.ts#L1040-L1043

Background

Common Parameters for Various Paths. Different API paths may have common parameters, such as pagination parameters. You can define common parameters under parameters in the global components section and reference them elsewhere via $ref. https://swagger.io/docs/specification/describing-parameters/

[maapteh]

duplicate for #510

[maapteh]

Some debug information so far:


ln#1053 on simple_schema_test the iteration "support components property in OpenAPI v3" gives me the following feedback.

The function addParameterSchema


I do see for Parameters the correct output

 for Components.Parameters.PathParameters, namely:



 
{ GeographyId: { '$ref': '#/components/parameters/GeographyId' } } 




since its input is

:



 

[ [ 'GeographyId', { name: 'geographyId', in: 'path', description: 'unique id of geography', required: true, schema: [Object] } ] ]
 



But after that for Paths.GetGeography.Parameters i do see "incorrect" output (index number instead of name):



 
[ [ '0', { '$ref': '#/components/parameters/GeographyId' } ] ] 




So the addParameterSchema is not called with an item name and so follows the index number.

[horiuchi]

@maapteh Thank you for your bug report 👍

This seems to be the same problem as #510.
The reason for the $0 is that when parsing parameters, the following code references name and uses it as the type name. But when using $ref, this code moves before expanding the reference, so name is not found and the type name is not taken.
https://github.com/horiuchi/dtsgenerator/blob/master/src/core/jsonSchema.ts#L242
This problem is due to the fact that OpenAPI support was added later, resulting in an unreasonable implementation.

In the future, we plan to make it possible to replace the type generator with different implementations for each version of JSON Schema and each version of OpenAPI, but we have been very busy and have not been able to make progress on this.

At this time, I think it would work better if you use $ref at schema instead of using $ref immediately below parameters.

[maapteh]

With common parameters setup i do not have the queryParams anymore per endpoint.

  export namespace FindProductsByCategory {
    export namespace Parameters {
      ...snip...
    }
    export interface QueryParameters {
      minPrice?: Parameters.MinPrice;
      maxPrice?: Parameters.MaxPrice;
      orderBy?: Parameters.OrderBy;
    }

So queryParameters are gone in total. I have not an option anymore. Will look further in what to do, what you advised me to do but i guess the retrieval of endpoints can not be done anymore since api's decided to have common parameters :)

Btw still a great library, lots of people learned about your generator when i got some feedback on my article about it!

[horiuchi]

Thanks for using dtsgenerator.
I hadn't done much hand-writing of OpenAPI definitions myself, so thanks to you I now know that this issue is quite important.

For this new comment, I would appreciate a detailed investigation if you would write down the actual input, the actual result, and the expected result.
However, it is probably the same cause of the problem I commented on last one.

[kostia1st]

Just wanted to let know that this issue is still relevant, and the fix would save the day for way more than one project.

[maapteh]

We moved to https://orval.dev/overview which besides creating all types (following api spec) also creates the complete hooks for integration for the frontend. Maybe you can have a look as well @kostia1st