nuanced.dev

large monorepos break most language servers. we hit the same wall, dug into what was going on, and ended up with a 10x speedup from an embarrassingly small change. full write-up is here: nuanced.dev/blog/how-we-ma… anyone who has worked in a huge monorepo knows how critical reliable code intelligence is. you can’t exactly build fast, safe tooling for agents or devs if your language server is constantly reindexing or timing out. as the repo grows, every slowdown compounds. we saw this while profiling nuanced lsp on large codebases. cold starts dragged on, CPU kept spiking, and even a simple “find references” call felt slow. we used the kubernetes repo as a stress test because it’s a classic example of a giant go codebase. and sure enough, gopls struggled there too. at first we assumed gopls just hates big repos. but it turned out gopls was doing exactly what we told it to. lsproxy, which nuanced lsp builds on, was walking the entire repo and collecting every `go.mod`, which made gopls try to initialize a workspace for each module at the same time. we fixed it by changing how root files are discovered, following what the gopls team actually recommends: - use a root `go.work` if it exists - otherwise only use the top-level go.mod - no recursion - fallback to repo root one workspace instead of hundreds competing. the impact was immediate. on the kubernetes test repo, indexing dropped from 6ish minutes to 36 seconds. cpu and memory stabilized, and cold starts became predictable. it looks like a tiny detail, but in large monorepos, these details matter! faster indexing means faster agents, faster dev tools, and a lot less wasted compute.

Blog link: nuanced.dev/blog/how-cente…