Open dan-cooke opened 1 month ago
Another easy solution with minimal change would be to follow the advice on this comment
If you wrapped the create/update hook requestBody types with this:
export type OmitReadonly<T extends object> = Omit<T, ReadonlyKeys<T>>
That would fix the ReadOnly part of this anyway..
Write only is a bit more involved so I believe having two separate type definitions - one for requesting, and one for responding is the best way
This library uses @hey-api/openapi-ts to generate the typescript models and service layer. The effort to fix that package would be better for the ecosystem IMO.
Thanks for the great lib, I've been looking for something to replace https://github.com/ferdikoomen/openapi-typescript-codegen as its no longer mantained.
There is quite a big issue on that old project too which was never fixed https://github.com/ferdikoomen/openapi-typescript-codegen/issues/432
There have been considerations to fix it in a fork => https://github.com/hey-api/openapi-ts/issues/28
But as of right now, they don't support react query codegen, so i'm out of options.
This library seems well mantained, and I like the API. So I would like to contribute to fixing this issue.
Describe the bug As per the OpenAPI spec for
readOnly
andwriteOnly
This implies that when a property is marked
readOnly
it should not be documented as part of the request objectTo Reproduce
OpenAPI spec file
Expected behavior
openapi/requests/types.gen.ts
should make a differentation between a requset and response schemaie.
Actual behaviour The ts
readonly
keyword is just prepended to fields with readonly, which is not semantically correct by OpenAPI spec