Typescript monorepo LSP performance
I recently converted a node and typescript monorepo to deno as an experiment to try out the monorepo support in deno. To my disappointment i noticed a severe slowdown in LSP performance in vscode with the deno extension for a medium sized monorepo (~15 packages, tens of thousands of lines of code, and LSP response times went from from a barely noticeable fraction of a second to a consistent 3-5 seconds delay)
This got me wondering, how does deno actually instrument the LSP for monorepos? Does it use one or several typescript projects under the hood, does it use project references?
My guess would be that deno just makes one typescript project, instead of one per package in the monorepo. At least that would explain the huge difference in performance compared to using multiple node and tsc based packages with project references.
Another thing this made me wonder about is what the ambition of deno is when it comes to typescript monorepo LSP performance. Is it within the scope of deno to have good LSP performance for large monorepos, or is this a problem that is meant to be solved by avoiding large codebases in deno?
8 Replies
deno just makes one typescript projectThat would be my guess too... ... unless you've configured your monorepo as a workspace. Have you done that? Or is it just a big repo with N unrelated codebases in it? https://docs.deno.com/runtime/fundamentals/workspaces/
Deno
Workspaces and monorepos
In-depth documentation, guides, and reference materials for building secure, high-performance JavaScript and TypeScript applications with Deno
Yes I did follow that guide! I made sure to set up workspaces properly in deno.
The next thing I'd check for is any
node_modules folders left over from the conversion from npm packages. (I'd hope not, but,) The language server might be trying to parse all of that code as part of your project. And node_modules directories can get quite large.
I believe the Deno team uses a monorepo for the std libraries. (https://jsr.io/@std), but that might be a smaller codebase than yours. If you don't get a response here in the next day or two, I'd suggest opening an issue on the Deno GitHub. They might also be able to provide more tips, or info on how to help track down the performance bottleneck.To clarify, I’m not asking for help to debug the issues in my repo. It could indeed be mistakes in my repo that causes a slow dx. However, my experiment mostly made me realize I don’t know how deno is supposed to perform, or what it actually does with the LSP under the hood in a monorepo. The docs doesn’t mention these type of details. So this thread was more to open a conversation about it in general, not to debug my project! I appreciate the ideas though, thanks!
The deno team does seem to be interested in a performant language server, btw. They even made a post about it a while back:
Recently, a customer reported significant performance issues with our language server in large codebases. Their feedback led us to investigate and optimize our language server, resulting in a dramatic reduction in auto-completion times - from 8 seconds to under one second. This blog post details how we achieved this improvement, from identifying the problem to implementing the solution.https://deno.com/blog/optimizing-our-lsp
That’s a great find! Thank you, I’ll give it a read!
good article! It sounds promising, at least there seems to be good focus on LSP performance. Still haven't been able to find any info on things like project references or specifically LSP for monorepo though.
FWIW, there are reports of LSP performance fixes in the latest deno release (v2.1.8). See if that improves things for you?
https://www.reddit.com/r/Deno/comments/1idwroh/deno_218_is_out/
Reddit
From the Deno community on Reddit: Deno 2.1.8 is out
Explore this post and more from the Deno community
Thanks for the tip! Yeah I’ll try out deno on my project again and see if it makes a noticeable difference