Typescript performance issues with caused by Convex types
We've been having some issues with the Typescript language server caused by
convex/_generated. After each edit in VScode it takes around 6 seconds for tsserver to have type info again. When I delete the _generated folder the issue is resvoled. But that also disables all Convex type hints.
Have other large Convex codebases encountered the same issue?
I can send over tsc perf traces in private if needed.6 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
I am experiencing some very very intense TS performance issues as well, especially in my frontend React files but to a slightly lesser extent also ini my Convex files.
I'm in a monorepo with two react native/expo frontend app. I tried analyzing my tsserver logs where I saw type resolution steps (i.e. IDE intellisense) taking >5 seconds, but couldn't make much sense of the trace - I passed it to an AI and it suggested that Convex was creating some very large type graphs that were slowing down the TS server/intellisense.
I haven't gotten any closer to solving it either, but would LOVE to hear advice - I like to think that I almost have a monk's anger control, but the 5-10 seconds intellisense times have driven me to banging my fists on the table 😆
I can confirm your finding! Deleting the
But yeah, this is not a solution, since it breaks types on all Convex-stuff in both backend and frontend files For further information, I have typed all Convex handler functions, e.g.
_generated folder gives me extra virgin intellisense speed in TS stuff 😻But yeah, this is not a solution, since it breaks types on all Convex-stuff in both backend and frontend files For further information, I have typed all Convex handler functions, e.g.
handler: async (ctx, args): Promise<void>. I think this improved the problem slightly, but I may just have been wishfully hallucinating - it wasn't anywhere near enough, at least.
I would like to try specifying returns: in all my convex function definitions, but im finding it cumbersome to work with validators for complex return types
did you figure out anything @Noah ?We are experiencing the same thing, and trying to figure out the best way to resolve. It kind of crept up on us and now it's very slow. Typescript Intellisense can take quite some time which hurts momentum.
If you haven't already seen this: https://github.com/microsoft/Typescript/wiki/Performance
There is a lot to that document and I'm still digesting it, but they have a diagnostic tool you can run before/after your changes to gauge improvements.
Also ensure you don't have any circular dependencies as those create unnecessary cycles. A good first step.
npx madge --circular --extensions ts,tsx src/ at your convex root. Or at your project root as well as you may have introduced some across application components.
skipLibCheck set to true in tsconfig can help, but read the caveat in that doc.
From there, I'm still trying to decide the best approach. Know that inference is always slower than explicit typing, for complex types, prefer extended interfaces over combined types. When we started, we used Doc<, Id<, z.infer, no explicit return types basically everywhere. Which I'd prefer to keep, as it's a bit of a pain to explicitly type all of these things as an alternative, and I'm still not sure how much it will boost performance.
If using vscode, bump up tsserver memory in your workspace settings: "typescript.tsserver.maxTsServerMemory".
Smaller files are better, extract helpers. If using a monorepo, you can extract things to separate packages, introduce a build step for them and import them using package imports (i.e. in pnpm, "@mm/shared": "workspace:*"). Especially for things that won't change very often. But here again you'll have to be careful not to introduce circular dependencies. Be thoughtful about how you organize things.
Once you do that, only open and work in smaller scoped workspaces, like /convex, or apps/frontend, whatever.
Can anyone from the convex team weigh in? Especially re: the idea of reducing usage of Doc<, Id<, z.infer?GitHub
Performance
TypeScript is a superset of JavaScript that compiles to clean JavaScript output. - microsoft/TypeScript
I spent a lot of time asking about this in the past, buying the fastest computer out there was my solution and switching to native Linux. My problem is lately its hard to tell where one utility ends and another starts. Like with cursor or windsurf aren't they augmenting the intelisense? I feel like recently i benefited from biome as having the formatter lag was delaying the typescript inference.
I'm also curious at what point will the rust version of typescript be ready. I was wondering if anyone tried to use it on a convex project.
Yes I deal with copilot fighting with my TS Intellisense. It's a huge pain. In VSCode they do have an aesthetic difference so I can tell which is which, but the timing (copilot is faster at this point, but wrong half the time) throws me off.
Do you mean the Go rewrite? I'm kind of hoping to properly resolve as many of the issues I can before that .... hides them all. 😛
yeah, go? whatever recently announced. If we could benchmark a project then we would know if strongly typing everything is ok, i use infer and objectType over 100 times on arrays of literals. I've not done it as i have 100s of functions to edit for a unknown amount of performance