Fix invalid $ref index into path

[duncanbeevers]

⚠️ The Error

Refs into the parameters array are turned into invalid indexes into the paths structure.

🗣️ Discussion

The problematic behavior is triggered using a $ref that points into the parameters array.
The problematic generated type then tries to index into ["parameters"]["0"] as though it were an array, when in fact it should be indexing into ["parameters"]["query"].

This particular weird ref was generated when I bundled a big schema with @apidevtools/json-schema-ref-parser.

🔧 Fix

• While parsing oapiRefs from parameters arrays, pass the resolved ParameterObject and use its in method to index into parameters type.

This probably doesn't work for more complex $refs, but I think it does slightly improve the semantic awareness of oapiRef.

[netlify]

👷 Deploy request for openapi-ts pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	bd77188

[changeset-bot]

⚠️ No Changeset found

Latest commit: bd77188

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[gzm0]

The problematic generated type then tries to index into ["parameters"]["0"] as though it were an array, when in fact it should be indexing into ["parameters"]["query"].

["parameters"]["path"][0] in the example? (otherwise I need to read up on how the ref "#/paths/~1endpoint/get/parameters/0" is supposed to work 😆 )

[duncanbeevers]

I was also not really familiar with that $ref syntax.

It took a bit of digging, but this portion of the $ref is defined by the JSON Pointer standard.

Evaluation of each reference token begins by decoding any escaped
character sequence. This is performed by first transforming any
occurrence of the sequence '~1' to '/', and then transforming any
occurrence of the sequence '~0' to '~'.

This ref is created during bundling, allowing the same schema to be used throughout the document without first extracting it to components/schemas. Instead, the first instance is inlined, and subsequent uses reference the initial inlined version via a JSON pointer.

However, this JSON Pointer is indexing into the OpenAPI structure, not the openapi-ts paths structure. It seems like there's some oversight in how that JSON Pointer is being transformed between OpenAPI land and openapi-ts land.

[duncanbeevers]

I feel like these refs were artificially-constructed to match the expected ts output, rather than extracted from a real OpenAPI ref.

Therefore, now that the parameter in is respected, I made them more realistic, and adjusted the custom resolver and expected test output.