Custom Fields in Document

[FrankEssenberger]

Dear open-api types team,

I was doing an update to version 9 recently and got a few type errors which where easy to fix. However, we have a wrapper for the openApi generator which adds some custom properties to the document e.g. x-my-additional-property which can be on the root, path or operation.

I saw that for the operation the type <T> goes down from the document so I could put an object containing the custom fields. However, for the PathItemObject I can not set the value for <P> on the Document which exposes only <T>.

I was wondering if these genric arguments are supposed to be used to put custom properties? If so it should be possible to set them all on the root object i.e. Document. I also think it would be nice to either have a single generic parameter holding all additional properties combined, or one for each location?

This is not a critical issue with Omit<> I could adjust the types as I needed but it would be nice if this works out of the box. I wanted to discuss the solution before I open a PR.

[teone]

I have the same issue, what is the workaround that you are using?

[FrankEssenberger]

We manually extended the types like here.

So the OperationNameExtended contains the explicit extension field name we use. Would be nicer to use `OperationType<{x-my-foo:string}> but to have the wrapper objects is also fine. The types are only there at design time anyway so the actual code includes the properties at runtime in a generic way.

[jsdevel]

@FrankEssenberger if you think there's a way to update the types please submit a PR. Thanks for raising this issue.

[akira28]

this lib: https://github.com/drwpow/openapi-typescript/blob/main/src/types.ts uses the Extensable interface for all the objects that should support x-whatever custom extensions.

export interface Extensable {
  [key: `x-${string}`]: any;
}

export interface InfoObject extends Extensable {
  /** REQUIRED. The title of the API. */
  title: string;
  /** A short summary of the API. */
  summary?: string;
  ...

would it make sense to improve the types package with something similar? I could work on a PR if owners of the repo agrees with it