Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Fields in Document #768

Open
FrankEssenberger opened this issue Sep 17, 2021 · 4 comments · May be fixed by #899
Open

Custom Fields in Document #768

FrankEssenberger opened this issue Sep 17, 2021 · 4 comments · May be fixed by #899

Comments

@FrankEssenberger
Copy link

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 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

on the Document which exposes only .

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
Copy link

teone commented Aug 2, 2022

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

@FrankEssenberger
Copy link
Author

FrankEssenberger commented Aug 2, 2022

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
Copy link
Contributor

jsdevel commented Aug 17, 2022

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

@akira28
Copy link

akira28 commented Mar 3, 2023

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

mitchell-merry added a commit to mitchell-merry/open-api that referenced this issue Mar 7, 2024
mitchell-merry added a commit to mitchell-merry/open-api that referenced this issue Mar 7, 2024
mitchell-merry added a commit to mitchell-merry/open-api that referenced this issue Mar 7, 2024
mitchell-merry added a commit to mitchell-merry/open-api that referenced this issue Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants