fix: support nested path parameters in --path-params-as-types

[barakalon]

Changes

The existing code for --path-params-as-types assumes path parameters are defined on the PathItemObject:

{
  openapi: "3.1",
  info: { title: "Test", version: "1.0" },
  paths: {
    "/user/{user_id}": {
      parameters: [{ name: "user_id", in: "path" }],
    },
  },
}

But its valid to define them on the OperationObject:

{
  openapi: "3.1",
  info: { title: "Test", version: "1.0" },
  paths: {
    "/user/{user_id}": {
      get: {
        parameters: [{ name: "user_id", in: "path" }],
      },
      put: {
        parameters: [{ name: "user_id", in: "path" }],
      }
    },
  },
}

FastAPI does it this way.

How to Review

This is both my first openapi-typescript PR and my first typescript PR. Don't hold back.

Checklist

• Unit tests updated
• README updated
• examples/ directory updated (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: ed0ab47

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-typescript	Patch

Not sure what this means? Click here to learn what changesets are.

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

[drwpow]

Great tests, and great code, thank you!

[mkosir]

This change made majority of query keys optional, which is unwanted behaviour since I can't access query parameters anymore.

[drwpow]

This change made majority of query keys optional, which is unwanted behaviour since I can't access query parameters anymore.

query keys being optional should only happen now when they are all optional. It shouldn’t happen if even one is required. This is actually more consistent with other types generated by this library, so I’m in favor of it.

However, if you have even one parameter that is required, then query should be required as well. If you find that happening, then please file a new issue (and no need for a reproduction; if that’s happening it should be easy to reproduce).

If you need to access that query object in types, you can always use the NonNullable<> built-in TS generic.

[mkosir]

Not sure if I'm in favour of this approach, but thanks for clarifying it.
Yes I use Required<>/NonNullable <>, find it a bit cumbersome to access parameter types.