search

jlalmes / trpc-openapi

OpenAPI support for tRPC 🧩
https://www.npmjs.com/package/trpc-openapi
MIT License
2.12k stars 136 forks source link

`trpc-openapi` tanks our Intellisense performance by 100% #433

Open divmgl opened 6 months ago

divmgl commented 6 months ago

Just a heads up that in our project trpc-openapi is tanking our Intellisense performance, specifically the TypeScript Language Server. Our getCompletionData calls go from 1.1s to 2.2s (100% performance degradation) just for having the package installed in the .meta section of our tRPC app.

I apologize I don't have a base repro for you (we can't share our internal codebase). You might be able to recreate this using tRPC's BigBoi test: https://github.com/trpc/trpc/blob/1d017dd603cdf32689258baa487bc43166d9d199/packages/tests/server/react/bigBoi.test.tsx#L4

timscullin commented 5 months ago

Same here. getCompletionData goes from 800ms to 1400ms when installing the package. We have about 200 routes, it seems the more we add the slower it goes.

Best workaround for now is to uninstall trpc-openapi locally and install it during build, but not ideal. Is there possibly a workaround to prevent it from running in our local dev environment?

divmgl commented 5 months ago

@timscullin that's a great workaround that we didn't think of. We ended up removing trpc-openapi completely from our stack since not many endpoints were instrumented.

I think a mix of solutions is needed so that this ecosystem's TypeScript compiler performance improves which IMO is the true underlying issue. It looks like the generated and inferred types from packages used with tRPC result in types that are too complex.

timscullin commented 5 months ago

@divmgl yeah agree, I was thinking about that looking at some other language server performance. This shouldn't really tank perf that bad though, as the open api endpoints don't require types as far as I am aware. Following to this ticket for updates 🙏