$ref in parameters not being transpiled

[wolfy1339]

Description

A brief description of the bug.

ReferenceObjects are not being transpiled into the types from the schema when used in OperationObject for the parameters field

This was working fine in 5.x, it stopped working in the 6.x releases.

Name	Version
openapi-typescript	6.0.3
Node.js	18.12.0
OS + version	macOS 13, Windows 11, etc.

Reproduction

How can this be reproduced / when did the error occur?
https://raw.githubusercontent.com/octokit/octokit-next.js/main/cache/types-openapi/ghes-3.2.json on line 431, for the /admin/hooks/{hook_id} path
Generated types: https://raw.githubusercontent.com/octokit/octokit-next.js/fix-types/packages/types-openapi-ghes-3.2/index.d.ts on line 17291

You can see that only the first parameter gets transpiled

Expected result

(in case it’s not obvious)

Checklist

• My OpenAPI schema passes a validator
• I’m willing to open a PR (see CONTRIBUTING.md)

[wolfy1339]

I retried with the code from #986 and it did not fix this problem

[wolfy1339]

Reposted from #989

I think that the problem could be in this part of the code https://github.com/drwpow/openapi-typescript/blob/main/src/transform/operation-object.ts#L72-L74

This is expecting paramIn to be part of the ref like components["parameters"]["query"]["limit"] but it is actually components["parameters"]["limit"]

Originally posted by @axelhzf in #989 (comment)

[drwpow]

@wolfy1339 yeah this is one area where it assumes there’s a hint in the $ref path about which type of param this is. I was trying to see if I could avoid doing an entire deep-pass over the whole schema to collect all parameters, but that may have to happen (which is tricky because we would not only need to collect all parameter definitions, but all $refs to parameters as well so they forward correctly).

In the meantime, please see the generated types here: https://github.com/drwpow/openapi-typescript/pull/997/files#diff-b43503415e823d5023ec484469dd542b2e2d6698bcc6112e4225053b9bab6dc7R83. Is this output acceptable as a workaround?

[wolfy1339]

I believe that would work.