I'm sure many of you have encountered statically-typed codebases so large and complicated that your code editors freeze, lag, become unresponsive, and generally struggle. Debugging a slow editor is involved and usually an unwelcome distraction. In many cases, slowness in code editors comes from language servers, which are external programs that provide language features (e.g. go-to-definition, diagnostics, type hints). Examples of developer frustrations: [1] and [2].

At a previous company, we were concerned about growing internal frustrations from editors bottle-necked by slow language servers. We were also concerned about how little insight we had into their performance and behaviour. So, we decided to instrument code editors and collect language server telemetry. The data we collected was shockingly useful and helped diagnose several major problems. For example, we identified certain modules in the codebase where the language server was much slower than normal. We subsequently found ways to break up these modules to reduce load on the language server.

I believe having this kind of data can be a game changer for managing developer experience, especially at scale. This is why I built lspwatch, a generalization of this tool which works with all LSP-compliant language servers and integrates with several observability backends.

Getting lspwatch up and running is very easy. Optionally configure your instrumentation, point it at your existing observability backend, and it will just work. lspwatch will transparently monitor language server behaviour and emit metrics. Developers won’t notice any difference in their code editors.

I welcome your feedback and thoughts. The README contains a lot more detail. Many exciting features are on the way to build on the platform this project provides. If you’d like to talk some more about this problem, email is in my profile.

Cheers!

[1] https://bsky.app/profile/mike.contribsys.com/post/3lbd5wx57s... [2] https://github.com/typescript-language-server/typescript-lan...