What's broken: In modules/swagger-codegen/src/main/resources/typescript-fetch/api.mustache, the file does import * as url from "url"; (line 5) and later calls url.parse(...) (line 104) and url.format(...) (line 238) inside each generated operation method. But generated method parameters are named directly from the OpenAPI spec's parameter names (line 93), with no collision check against url. AbstractTypeScriptClientCodegen's reserved-word list (lines 53-58) covers TS keywords and a few internal names but not url, and TypeScriptFetchClientCodegen doesn't add it either.
Result: Any operation with a parameter literally named url (e.g. GET /webhooks?url=...) generates a method like:
listWebhooks(url?: string, options: any = {}): FetchArgs {
const localVarUrlObj = url.parse(localVarPath, true); // url = the string param, not the module
...
return { url: url.format(localVarUrlObj), options: localVarRequestOptions };
}
Because the parameter is typed string, this isn't a subtle runtime issue — it's a hard tsc compile error: Property 'parse' does not exist on type 'string'.
Repro spec: minimal Swagger 2.0 doc with one GET operation taking a query param named url — included in full in the saved file.
Related prior art: #6698 (closed, fixed by PR #6717) fixed an almost identical collision for a parameter named path, but only by renaming the template's local variables to localVar*-prefixed names. That fix never touched the import * as url from "url" binding, so this specific case slipped through and is still present on current master (c7dd2fc, pom 2.4.53-SNAPSHOT).
Suggested fix (recommended): alias the import, e.g. import * as _nodeUrl from "url";, and use _nodeUrl.parse/_nodeUrl.format in the template — fixes the whole class of import-vs-parameter-name collisions without touching generated public API (param names, FetchArgs.url, etc. stay the same). Alternatives: add url to the reserved-word list so it gets escaped like other reserved names, or stop relying on a bare top-level import that any parameter name can shadow.
What's broken: In modules/swagger-codegen/src/main/resources/typescript-fetch/api.mustache, the file does import * as url from "url"; (line 5) and later calls url.parse(...) (line 104) and url.format(...) (line 238) inside each generated operation method. But generated method parameters are named directly from the OpenAPI spec's parameter names (line 93), with no collision check against url. AbstractTypeScriptClientCodegen's reserved-word list (lines 53-58) covers TS keywords and a few internal names but not url, and TypeScriptFetchClientCodegen doesn't add it either.
Result: Any operation with a parameter literally named url (e.g. GET /webhooks?url=...) generates a method like:
listWebhooks(url?: string, options: any = {}): FetchArgs {
const localVarUrlObj = url.parse(localVarPath, true); //
url= the string param, not the module...
return { url: url.format(localVarUrlObj), options: localVarRequestOptions };
}
Because the parameter is typed string, this isn't a subtle runtime issue — it's a hard tsc compile error: Property 'parse' does not exist on type 'string'.
Repro spec: minimal Swagger 2.0 doc with one GET operation taking a query param named url — included in full in the saved file.
Related prior art: #6698 (closed, fixed by PR #6717) fixed an almost identical collision for a parameter named path, but only by renaming the template's local variables to localVar*-prefixed names. That fix never touched the import * as url from "url" binding, so this specific case slipped through and is still present on current master (c7dd2fc, pom 2.4.53-SNAPSHOT).
Suggested fix (recommended): alias the import, e.g. import * as _nodeUrl from "url";, and use _nodeUrl.parse/_nodeUrl.format in the template — fixes the whole class of import-vs-parameter-name collisions without touching generated public API (param names, FetchArgs.url, etc. stay the same). Alternatives: add url to the reserved-word list so it gets escaped like other reserved names, or stop relying on a bare top-level import that any parameter name can shadow.