-
Notifications
You must be signed in to change notification settings - Fork 827
simplify return types #119
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
Comments
There are already aliases for return types. Have you tried SDK version 1.1.1, incorporating #114? It should make this case better, more akin to just using TS types (but still using Zod under the hood). |
I tried building the git main branch and saw the complex types in the generated d.ts file for example in dist/*/client/index.d.ts. Then I declared the return type of the method and the problem went away. |
Related #182 These types would be a lot more straightforward if it didn't use |
Hey folks, inferring types from zod schemas is very expensive computationally, and seems unnecessary for a library. Ideally you just have static types - should be fairly easy to generate. I'm sure there are scripts that do this. |
…/ashwin/font feat: use monospace font for all input fields in sidebar
Is your feature request related to a problem? Please describe.
the d.ts files are currently way too complex, for example this is one method of the client api.
Describe the solution you'd like
a very simple fix would be to just create aliases for the return types and use them:
Describe alternatives you've considered
a even better version IMO would be to not use zod at all for the return types, just declare typescript types, and let typescript check if they are compatible.
The text was updated successfully, but these errors were encountered: