-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
TS compilation perf: steal faster extendShape type from tRPC #2839
TS compilation perf: steal faster extendShape type from tRPC #2839
Conversation
✅ Deploy Preview for guileless-rolypoly-866f8a ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
I feel like there are edge cases where dropping I'll do a little more testing then merge. Thanks! |
FWIW I can try to run some perf tests on how much keeping |
Used this: https://github.com/jussisaurio/zod-ts-perftest (there are already pregenerated zod schemas in the repo) Running master: 4.51s, 4.56s, 4.51s Not too much of a difference at all between keeping or removing |
We use extend quite a bit. This PR is a marked improvement. zod 3.22.4:
zod 3.22.4 with this patch:
The time to check the whole app isn't a big deal, but VSCode's TS intellisense is a pain. It slowed down substantially after I rewrote a bunch of schemas using extend. We have a number of nested extend schemas in big unions. |
Merged a variant in #2845 Thanks! |
I have some empirical evidence in a decently sized closed-source project that liberal use of
ZodObject.extend()
seems to degrade TS compilation and intellisense performance quite rapidly. I remembered seeing an equivalent implementation ofextendShape
in tRPC (in that project, calledOverwrite
) that looked simpler. I did some light profiling on it using said closed-source project and here are the results:Main thing (apart from faster runtime) is the dramatically lower number of type instantiations.