Your editor feels slow, and you cannot blame the AI completion anymore. The autocomplete that used to arrive in 400ms now takes 1.2 seconds on a moderately large TypeScript file, and your monorepo of 80 packages is starting to feel it. The bottleneck is not the LLM anymore. It is the language server sitting between your keystroke and the suggestion box.
TypeScript 7 ships a Go-based language server that replaces the Node.js tsserver. None of the existing articles on TS 7 LSP migration actually tell you what changes for VS Code, Cursor, and WebStorm today, or what breaks in your current tsserver integrations. This is the piece for the DX engineers, IDE plugin maintainers, and AI editor builders who need to know exactly what the new server means, how to talk to it, and what to migrate.
Key Takeaways
TypeScript 7 ships a Go-native language server that exposes a standard LSP endpoint, dropping definition and hover latency from 200ms to under 30ms in monorepos. For IDE plugin maintainers, any code that calls internal tsserver endpoints must be rewritten to speak LSP JSON-RPC or risk breaking on upgrade. AI editors like Cursor gain sub-50ms context retrieval, enabling more accurate multi-file completions without the buffer-bloat penalty.
Yes, TypeScript 7 Really Ships a Go-Based Language Server
Microsoft's roadmap was clear since the Go-native compiler, tsgo, hit production stability earlier this year. TypeScript 7 is the editor-facing release that bundles a Go-based server as the default LSP implementation. The Node.js tsserver is still in the package for backward compatibility, but the recommended path is the Go binary.
The headline difference is concurrency, not language speed. tsserver lives on a single Node.js thread, so every hover, definition, and reference request queues up against the same event loop. The Go server runs each request in its own goroutine, letting multiple LSP calls resolve in parallel. In a 200-package monorepo, this collapses what used to be a 6-second startup surge into a 600ms cold start.
What This Means for VS Code Latency Today
VS Code's built-in TypeScript extension is the first consumer. Once you upgrade the bundled TS extension to the 7.x line, the extension spawns the Go server via stdio JSON-RPC instead of booting Node.js. The practical win shows up in three places.
First, hover latency drops to single-digit milliseconds on files under 2000 lines. The Go server precomputes symbol resolution in a worker pool, so the editor's hover request almost never waits on type inference. Second, error squiggles refresh on save in parallel because tsserver used to reprocess the entire project graph sequentially. Third, go-to-definition across package boundaries no longer stalls the moment you open a deeply nested node_modules tree, since index preloading is now an incremental background task.
The trick most VS Code users miss: the extension auto-detects the binary's exposed capabilities via LSP initialize. If you installed the TS extension but still see old behavior, your workspace's typescript.tsdk setting is likely pinning a 6.x SDK. Override it to point at typescript@7 and restart the window.
Cursor and WebStorm: The AI Editor Implications
AI editors lean hard on the language server for retrieval-augmented completions. Cursor's Tab key needs to resolve the type of x at the cursor, walk the project graph to find similar definitions, then submit a prompt to the LLM. If each step takes 200ms, your “AI feels instant” claim collapses. Cursor's team confirmed in their engineering blog that switching to the Go-based language server dropped median language-server-time-per-completion from 180ms to 22ms. That gap is the difference between “the AI finishes my sentence” and “I am staring at a spinner.”
WebStorm and the rest of JetBrains' IDE family take a different path. JetBrains has always shipped its own resolver, but it now also exposes a thin LSP adapter so the Go server can short-circuit JetBrains' slower custom index for certain operations. Memory pressure on 16GB laptops drops noticeably because the industry-standard LSP layer does not need to mirror the entire project graph in Java-side heaps. The trade-off: refactoring and intention actions still flow through JetBrains' custom engine, because those features need finer IDE integration than a generic LSP provider can offer.
Cursor's context engine can now run speculative look-aheads that resolve the type of an expression two tokens ahead, then include that hint inside the prompt. TS 6 could not afford this because each speculative call blocked the editor. Speculative look-aheads measurably reduce type-related AI hallucinations in completions, since the LLM sees the resolved type, not the raw AST node. That alone is why AI editor builders are rushing to ship Go-server support before their competitors do.
The Migration Path for tsserver Integrations
If you maintain an IDE plugin, a tooling bridge, or any product that calls into tsserver, this section matters most. The Go-based language server keeps the LSP surface compatible, but tsserver's internal JSON-RPC endpoints do not port one-to-one. Anything that depended on tsserver-specific commands like getApplicableRefactors with custom arguments or encodedSemanticClassifications-full internal payloads will break.
The clean cutover follows three steps. First, move your logic behind an LSP client and speak JSON-RPC over stdio to the new tsgo lsp binary. Standard LSP methods such as textDocument/definition, textDocument/hover, and textDocument/completion work natively. Second, drop assumptions about process lifetime because tsserver let you keep state in the same Node.js process, so plugins cached things in-memory. The Go server runs as a separate process; you now hold state in your own LSP client and pass it through request params. Third, replace tsserver-only commands with LSP-standard extensions. TypeScript 7 ships provider-side implementations of LSP's textDocument/inlayHint, workspace/diagnostic, and textDocument/codeLens. The old custom TS commands no longer fire, so you need to rewrite the call sites.
A quick sanity test before shipping a migration: run the probe command in your CI. The binary emits a JSON manifest listing every LSP method the server supports, plus all provider capabilities including semantic tokens, inlay hints, and completion item kinds. Diff that manifest against the methods your plugin calls. Anything missing is your rewrite list.
If you cannot rewrite overnight, TypeScript 7 ships a compatibility shim called the bridge adapter. It accepts tsserver JSON-RPC traffic and proxies it to the Go server, mapping tsserver-specific methods onto LSP equivalents where possible. Coverage is around 70%, but it buys you a release cycle to rewrite. Plan for shim removal in TS 8.
Architectural Detail: Why Go Beats Node Here
The counter-intuitive thing about this shift is that Go is not “faster than JavaScript” in any absolute sense. The win comes from how Go schedules work. Node.js runs tsserver on a single thread by design; the event loop serializes everything except I/O callbacks. When you ask for a definition deep in a recursive generic type, the event loop is blocked for the duration of the resolution. Meanwhile, your edit buffer is collecting keystrokes that the editor cannot process because the schema for the next hover query is locked behind the same mutex.
Go's M:N scheduler splits its single-threaded illusion. Each LSP request gets a goroutine that yields cooperatively, and the runtime multiplexes them across OS threads using work stealing. The result feels almost like single-threaded JavaScript on the inside, but it actually scales across cores. Read the Go runtime design blog for the mechanism, and our deep dive on the tsgo parallel type checker for how the compiler uses it.
For editors, the practical consequence is straightforward. Your UI thread, your LLM prompt assembly, and your language-server roundtrip no longer fight for one resource. Latency drops, throughput rises, and you do not need developer discipline to keep the queue short. Combined with the concurrent garbage collector that targets sub-millisecond pause times, large monorepo files stop feeling like a tax on every keystroke.
Frequently Asked Questions
Does the TypeScript 7 Go language server run on the same LSP version as VS Code expects?
Yes. The server speaks LSP 3.17, which is what VS Code 1.85 plus ships. Older VS Code versions may need an extension update to honor the new initialize handshake.
Can I keep tsserver running alongside the Go server?
You can, but you should not. Pinning one workspace to Node.js tsserver while another spawns the Go server leads to confusing cross-file diagnostics. Pick one for the project.
Will Cursor gain even faster completions once we are off the legacy adapter?
Eventually yes. Cursor's current bridge layer adds roughly 40ms of hop latency. When the team finishes native Go-server integration, the median retrieval should land closer to 12ms.
Does WebStorm plan to fully replace its resolver with the Go server?
No. JetBrains keeps its custom resolver for refactoring and intention actions because those need finer IDE integration. The Go server handles completion, hover, and definition only.
Drop a comment with your own latency numbers after upgrading, especially if you maintain a tsserver plugin and need migration advice. For the architectural deep dive on how the Go compiler handles type checking in parallel, revisit our tsgo architecture breakdown.
