[typescript-fetch] 2.3.0 changes how parameters are passed to methods

[janslow]

Description

In 2.2.3 and below, the typescript-fetch generator accepted method parameters in an object, but 2.3.0 has regressed/made a very breaking change so that all parameters have to be passed individually:

e.g.,

# 2.2.3
public getFoo(params: {  "id": string; }, options?: any) { ... }

# 2.3.0
public getFoo(id: string, options?: any) { ... }

I couldn't find any reference to this as a deliberate change in any of the release notes

Swagger-codegen version

2.3.0 (regressed since 2.2.3)

Steps to reproduce

Generate any operation with parameters using typescript-fetch.

Related issues/PRs

I eventually managed to track the regression down to #6130, as api.mustache was completely rewritten when it was "copied" from here to here. Here is a diff of the changes which were made in #6130 to api.mustache, as Git/GitHub didn't detect a rename and show a useful diff (due to the number of changes).

The 2.2.3 behaviour for typescript-fetch was inconsistent with the behaviour for typescript-angular, so there is an existing issue saying that typescript-angular should accept params in an object

Suggest a fix/enhancement

Restore method signature to 2.2.3 form.

[sbusch]

Besides the breaking change, I think it's a bad idea to use positional arguments and wonder what's the reasoning behind this.

@isman-usoh can you comment on this?

Depending on the position of arguments means a changed order could easily break the generated API

Another problem: our API uses an "options" parameter. Because the typescript-fetchgenerator appends it's own "options?: any", there is a name collision:

Failed to compile.

Module parse failed: Argument name clash (5251:89)
You may need an appropriate loader to handle this file type.
|          * @throws {RequiredError}
|          */
|         findEntity: function (name, options, options) {

Method signature in TypeScript

public findEntity(name: string, options?: string, options?: any) {