astahmer
Large OpenAPI schemas drastically impact the performance of Typescript language servers
Current working with a schema which results in 325 Zod schema objects and 214 endpoints, with the current default template this results in the exported schema and the parameters of the makeApi call being large monolithic objects. It appears Typescript when accessing the property of a regular object will parse the entire object, this causes language servers when performing type checking or hinting within the scope of autogenerated code to significantly slow down (~10s for hints to appear on the exported api, ~4s for the schemas object), this is made worse by most LSP's being single-threaded and synchronous so this locks up LSP functionality until the command in scope terminates or times out.
Mentioned above that this applies to regular objects, what it doesn't apply to is modules. Have verified that Typescript handles modules (including when aliasing wildcard imports) differently, appears to only parse relevant scopes within the module and is significantly faster as a result (no noticeable performance issues when using a custom template which removes schemas and creates const <endpoint> variables instead of inlining the makeApi parameters).
May not be a good idea to implement these changes in the default schema, doing so would be a breaking change for existing users of the library. Previously opened the feature request #130 and this seems like a good candidate for a first-party optional template, would reduce the burden on consumers of openapi-zod-client as they wouldn't be forced to maintain custom templates to patch this issue.
ok so, what you're saying is : typescript (and/or) zodios type inference leads to slow autocomplete, which could be fixed by referencing each endpoint to an associated variable rather than just inlining the whole endpoint list ? and this could be done in a custom (but built-in) template
this would be nice indeed ! as usual, feel free to open a PR for that (with a changeset)
