TypeScript 100 ๐ท Language Server Protocol and Editor Integration
The Language Server Protocol is the interface that lets editors and IDEs provide rich language features โ completions, diagnostics, hover information, go-to-definition, refactoring โ without implementing a language’s compiler inside the editor itself. A language server runs as a separate process, communicates with the editor through a standardized protocol, and exposes the language’s semantic model to any editor that speaks the protocol. TypeScript’s implementation of this model is called tsserver, and it predates the LSP itself. In fact, the LSP was born from the TypeScript server’s protocol .
Key point: The LSP is a language-neutral protocol. It defines the messages that an editor and a language server exchange, regardless of which language the server implements. TypeScript’s tsserver uses its own JSON protocol, which is not the LSP. A separate community project, typescript-language-server, wraps tsserver and exposes it through the LSP so that editors outside VS Code can use standardized plumbing . TypeScript 7.0 is changing this by adding native LSP support .
Why the Language Server Protocol exists
Before the LSP, every editor that wanted to support a language had to implement that language’s tooling inside the editor itself. The Eclipse CDT plugin for C/C++ was written in Java because Eclipse is written in Java. A Visual Studio Code plugin for C/C++ would have to be written in TypeScript, and a Visual Studio plugin in C#. The same language’s domain model had to be reimplemented for every editor. With n editors and m languages, the number of plugins required was n ร m .
The LSP changes the equation to n + m. Each language implements one language server. Each editor implements one LSP client. Any editor can talk to any server. The protocol standardizes the messages: textDocument/completion for completions, textDocument/hover for hover information, textDocument/definition for go-to-definition, and so on. The editor does not need to understand the language’s internal model. It only needs to send the right request and render the response .
The LSP started with OmniSharp for C#, then the TypeScript server, and was standardized by the VS Code team. The TypeScript server’s protocol was the foundation. The LSP extended it with more language features inspired by the VS Code language API. JSON-RPC was chosen for the remote invocation because of its simplicity and existing libraries .
a. tsserver: The TypeScript Standalone Server
tsserver is a Node.js executable that encapsulates the TypeScript compiler and language services. It exposes them through a JSON protocol defined in tsserverlibrary.d.ts. The server listens on stdin and writes responses to stdout. Each message is a JSON object with a header that includes the content length, followed by the JSON body .
A request to open a file looks like this:
{"seq":1,"type":"request","command":"open","arguments":{"file":"c:/project/index.ts"}}
A response to a quick-info request looks like this:
Content-Length: 116
{"seq":0,"type":"response","command":"quickinfo","request_seq":2,"success":false,"message":"No content available."}
The server supports a set of commands: open, close, completionInfo, quickinfo, definition, references, rename, geterr, geterrForProject, format, organizeImports, getCodeFixes, and many more. Each command has a corresponding request and response interface in the protocol definition .
VS Code’s TypeScript support is built on tsserver. The built-in typescript-language-features extension spawns the server as a child process and communicates with it using the JSON protocol. VS Code does not use the LSP for TypeScript โ it uses tsserver directly. This is why VS Code’s TypeScript support is richer and more responsive than editors that rely on the LSP wrapper .
b. typescript-language-server: The LSP Wrapper
Editors outside VS Code โ Neovim, Emacs, Sublime Text, Helix โ do not want to implement the tsserver protocol. They want to speak the LSP because their LSP client infrastructure already exists. The typescript-language-server project bridges the gap. It is a community-maintained server that implements the LSP and translates LSP requests into tsserver requests .
The server is installed with npm:
npm install -g typescript-language-server typescript@6
It is started with the --stdio flag and communicates with the editor over standard input and output. The editor sends LSP requests. The server translates them to tsserver commands, forwards them to a spawned tsserver process, receives the response, and translates it back to an LSP response .
The server exposes TypeScript-backed code actions, workspace commands, code lenses, inlay hints, formatting requests, and passthrough commands that allow the editor to send raw tsserver commands when the LSP does not have an equivalent . The project is not maintained by Microsoft and is not used in VS Code. It exists purely for editors that want TypeScript support through LSP plumbing .
The translation is not perfect. Some TypeScript-specific features โ like the “Move to File” refactor, which requires user input that the LSP does not have a standard for โ cannot be exposed through the LSP without custom extensions. The server implements these as custom workspace commands with the _typescript. prefix .
c. TypeScript 7.0 and Native LSP Support
TypeScript 7.0, released in July 2026, is a native Go port of the compiler that delivers 8xโ12x speedups on full builds. A full build of the VS Code codebase, for example, fell from 125.7 seconds to 10.6 seconds. Opening a file with an error dropped from 17.5 seconds to under 1.3 seconds .
The performance gain comes from native code, shared memory multithreading, and a more efficient traversal of the syntax graph. The language service has been rewritten to use the LSP natively. VS Code has a dedicated TypeScript 7 extension, and support is being migrated from the older tsserver design to the LSP .
This change matters for editors outside VS Code. When TypeScript 7.0 ships with native LSP support, the community typescript-language-server wrapper may become unnecessary. The native server will speak LSP directly, and any LSP-capable editor can use it without a translation layer. The typescript-language-server maintainers acknowledge this: “Currently Microsoft is working on TypeScript 7 written natively in the go language that will include the LSP implementation and will hopefully supersede this project” .
The migration is not complete. tsserver still exists in TypeScript 7.0, and VS Code still uses it for some features. But the direction is clear: the LSP is the future of TypeScript editor integration, and the standalone server is being replaced by a native LSP server .
Complete Example Session
This session demonstrates how an editor communicates with tsserver, how the LSP wrapper translates requests, and how the TypeScript 7.0 change affects the setup.
// ============================================
// PART 1: A REQUEST TO TSSERVER
// ============================================
// The editor sends a request to open a file
// {"seq":1,"type":"request","command":"open","arguments":{"file":"/project/index.ts"}}
// tsserver responds with the file's syntactic diagnostics
// {"seq":0,"type":"event","event":"syntaxDiag","body":{"file":"/project/index.ts","diagnostics":[]}}
// ============================================
// PART 2: A COMPLETION REQUEST
// ============================================
// The editor sends a completion request
// {"seq":2,"type":"request","command":"completionInfo",
// "arguments":{"file":"/project/index.ts","line":5,"offset":10}}
// tsserver responds with the completion entries
// {"seq":0,"type":"response","command":"completionInfo","request_seq":2,"success":true,
// "body":{"isGlobalCompletion":false,"isMemberCompletion":false,
// "entries":[{"name":"length","kind":"property","sortText":"0"}]}}
// ============================================
// PART 3: THE LSP EQUIVALENT
// ============================================
// The editor sends an LSP completion request
// {"jsonrpc":"2.0","id":1,"method":"textDocument/completion",
// "params":{"textDocument":{"uri":"file:///project/index.ts"},
// "position":{"line":5,"character":10}}}
// typescript-language-server translates it to a tsserver request,
// gets the response, and translates it back to LSP
// {"jsonrpc":"2.0","id":1,"result":{
// "isIncomplete":false,
// "items":[{"label":"length","kind":10,"sortText":"0"}]}}
// ============================================
// PART 4: THE VS CODE CONFIGURATION
// ============================================
// .vscode/settings.json
{
"js/ts.tsdk.path": "node_modules/typescript/lib",
"js/ts.tsdk.promptToUseWorkspaceVersion": true
}
// The tsdk.path setting tells VS Code to use the workspace's
// TypeScript version instead of the bundled version.
// The prompt setting controls whether VS Code asks the user
// to confirm the switch .
// ============================================
// PART 5: THE NEVOIM CONFIGURATION
// ============================================
// Neovim uses the LSP client and typescript-language-server
// require('lspconfig').tsserver.setup({
// cmd = { "typescript-language-server", "--stdio" },
// root_dir = require('lspconfig.util').root_pattern("tsconfig.json"),
// })
// The LSP client sends LSP requests.
// typescript-language-server translates them to tsserver.
// ============================================
// PART 6: THE TSSERVER LOG
// ============================================
// Set the TSS_LOG environment variable to capture the protocol
// TSS_LOG="-level verbose -file /tmp/tsserver.log"
// The log contains every request and response.
// It is the primary debugging tool for editor integration issues.
// ============================================
// PART 7: THE LANGUAGE SERVICE PLUGIN
// ============================================
// A TypeScript language service plugin can extend tsserver's behavior.
// It is registered in tsconfig.json:
// { "compilerOptions": { "plugins": [{ "name": "my-plugin" }] } }
// The plugin receives the language service and can proxy its methods.
// It can modify completions, refactorings, and diagnostics .
// ============================================
// PART 8: THE TYPESCRIPT 7.0 CHANGE
// ============================================
// TypeScript 7.0 ships with native LSP support.
// VS Code uses a dedicated TypeScript 7 extension.
// The community typescript-language-server may become unnecessary.
// For editors that already speak LSP, the transition is transparent.
// The server command changes, but the protocol remains the same.
// ============================================
// PART 9: THE DEBUGGING WORKFLOW
// ============================================
// To debug tsserver:
// 1. Set TSS_DEBUG to an open port
// 2. Launch VS Code with the development TypeScript build
// 3. Attach the debugger to the port
// The server-side code lives in src/services and src/server
// of the TypeScript repository. The client-side code lives in
// extensions/typescript of the VS Code repository .
// ============================================
// PART 10: THE SUMMARY
// ============================================
// tsserver: TypeScript's standalone server, JSON protocol.
// LSP: language-neutral protocol, n + m plugins instead of n ร m.
// typescript-language-server: LSP wrapper around tsserver.
// TypeScript 7.0: native LSP support, Go-based compiler.
The ten parts cover a tsserver request, a completion request, the LSP equivalent, VS Code configuration, Neovim configuration, tsserver logging, language service plugins, the TypeScript 7.0 change, debugging workflow, and the summary.
Quick Reference
The Protocol Comparison
| Aspect | tsserver | LSP |
|---|---|---|
| Scope | TypeScript/JavaScript | Any language |
| Protocol | Custom JSON | JSON-RPC 2.0 |
| Transport | stdin/stdout | stdio, sockets |
| Editor support | VS Code, others | Any LSP client |
| Native support | TypeScript | Standardized |
The Key Projects
| Project | Purpose |
|---|---|
tsserver | TypeScript standalone server |
typescript-language-server | LSP wrapper around tsserver |
typescript-language-features | VS Code extension |
| TypeScript 7.0 | Native LSP server |
The LSP Request Methods
| Method | Purpose |
|---|---|
textDocument/completion | Code completions |
textDocument/hover | Hover information |
textDocument/definition | Go to definition |
textDocument/references | Find references |
textDocument/rename | Rename symbol |
textDocument/codeAction | Refactoring and fixes |
textDocument/formatting | Format document |
The tsserver Commands
| Command | Purpose |
|---|---|
open | Open a file |
close | Close a file |
completionInfo | Get completions |
quickinfo | Get hover info |
definition | Get definition location |
references | Get reference locations |
rename | Get rename edits |
geterr | Get semantic diagnostics |
format | Format a file |
organizeImports | Organize imports |
The Configuration Settings
| Setting | Purpose |
|---|---|
js/ts.tsdk.path | Use workspace TypeScript |
js/ts.tsdk.promptToUseWorkspaceVersion | Prompt for workspace version |
TSS_LOG | Enable tsserver logging |
TSS_DEBUG | Enable tsserver debugging |
Best Practices
โ Do This:
// Use the workspace TypeScript version in VS Code
{ "js/ts.tsdk.path": "node_modules/typescript/lib" } // โ
# Use typescript-language-server for LSP editors
npm install -g typescript-language-server typescript@6 // โ
# Enable tsserver logging for debugging
TSS_LOG="-level verbose -file /tmp/tsserver.log" // โ
// Write a language service plugin to extend tsserver
// { "compilerOptions": { "plugins": [{ "name": "my-plugin" }] } } // โ
โ Don’t Do This:
# Don't try to connect to tsserver using LSP
# tsserver uses its own JSON protocol, not LSP. // โ
// Don't put tsdk.path in user settings if the path is relative
// It must be relative to the workspace folder. // โ
// Don't assume all TypeScript features are available in LSP
// Some features require tsserver-specific extensions. // โ
Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| LSP client cannot connect | Using LSP to talk to tsserver | Use typescript-language-server wrapper |
| Editor shows older TypeScript | Using bundled version | Set js/ts.tsdk.path |
| Missing completions | Language server not started | Check the editor’s LSP configuration |
| Slow diagnostics | Large project, no incremental | Use tsserver project system |
| TypeScript 7.0 LSP not working | Using old typescript-language-server | Use native TypeScript 7 LSP |
Real-World Examples
1. tsserver Request
{"seq":1,"type":"request","command":"open","arguments":{"file":"/project/index.ts"}}
2. tsserver Response
Content-Length: 116
{"seq":0,"type":"response","command":"quickinfo","request_seq":2,"success":false}
3. LSP Completion Request
{"jsonrpc":"2.0","id":1,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///project/index.ts"},"position":{"line":5,"character":10}}}
4. VS Code Setting
{ "js/ts.tsdk.path": "node_modules/typescript/lib" }
5. Neovim LSP Setup
require('lspconfig').tsserver.setup({ cmd = { "typescript-language-server", "--stdio" } })
6. tsserver Logging
TSS_LOG="-level verbose -file /tmp/tsserver.log" tsserver
7. Language Service Plugin
{ "compilerOptions": { "plugins": [{ "name": "my-plugin" }] } }
8. Debug tsserver
TSS_DEBUG=5859 code --user-data-dir=/tmp/vscode-dev
9. TypeScript 7.0 LSP
# VS Code has a dedicated TypeScript 7 extension
# The native server speaks LSP directly
10. typescript-language-server
typescript-language-server --stdio
Visual
The LSP Architecture
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ LSP ARCHITECTURE โ
โ โ
โ Editor (LSP client) โ
โ โ โ
โ โ JSON-RPC over stdio โ
โ โผ โ
โ Language Server (LSP server) โ
โ โ โ
โ โผ โ
โ Language domain model โ
โ (compiler, parser, checker) โ
โ โ
โ n editors + m languages = n + m plugins โ
โ Without LSP: n ร m plugins โ
โ โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The TypeScript Editor Integration
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ TYPESCRIPT EDITOR INTEGRATION โ
โ โ
โ VS Code: โ
โ typescript-language-features โ
โ โโ spawns tsserver โ
โ โโ JSON protocol (stdin/stdout) โ
โ โ
โ Neovim / Emacs / Sublime: โ
โ LSP client โ
โ โโ typescript-language-server โ
โ โโ wraps tsserver โ
โ โโ translates LSP โ tsserver โ
โ โ
โ TypeScript 7.0: โ
โ Native LSP server (Go) โ
โ โโ No wrapper needed โ
โ โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The tsserver Protocol
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ TSSERVER PROTOCOL โ
โ โ
โ Request: โ
โ {"seq":1,"type":"request", โ
โ "command":"completionInfo", โ
โ "arguments":{"file":"...", "line":5, โ
โ "offset":10}} โ
โ โ
โ Response: โ
โ Content-Length: <n> โ
โ {"seq":0,"type":"response", โ
โ "command":"completionInfo", โ
โ "request_seq":1,"success":true, โ
โ "body":{"entries":[...]}} โ
โ โ
โ Event: โ
โ {"seq":0,"type":"event", โ
โ "event":"semanticDiag", โ
โ "body":{"file":"...", "diagnostics":[...]}}โ
โ โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The TypeScript 7.0 Change
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ TYPESCRIPT 6 vs 7 EDITOR SUPPORT โ
โ โ
โ TypeScript 6: โ
โ tsserver (Node.js) โ
โ Custom JSON protocol โ
โ VS Code uses tsserver directly โ
โ Other editors use wrapper โ
โ โ
โ TypeScript 7: โ
โ Native server (Go) โ
โ Native LSP support โ
โ VS Code uses dedicated extension โ
โ Other editors use LSP directly โ
โ โ
โ Speedup: 8xโ12x on full builds โ
โ Editor: <1.3s to open file with error โ
โ โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Summary
| Item | Value |
|---|---|
| LSP | Language Server Protocol, language-neutral |
| LSP purpose | n + m plugins instead of n ร m |
| tsserver | TypeScript standalone server |
| tsserver protocol | Custom JSON over stdin/stdout |
| LSP wrapper | typescript-language-server |
| VS Code integration | Uses tsserver directly |
| Neovim/Emacs integration | Uses LSP wrapper |
| TypeScript 7.0 | Native LSP support, Go compiler |
| Debugging | TSS_LOG, TSS_DEBUG |
| Workspace TypeScript | js/ts.tsdk.path |
Key takeaways:
- The LSP is the standardized protocol between editors and language servers. It defines the messages for completions, diagnostics, hover, definition, rename, and refactoring. The
n + marchitecture replaces then ร mmodel of per-editor plugins . tsserveris TypeScript’s standalone server. It predates the LSP and uses its own JSON protocol over stdin/stdout. VS Code communicates with it directly. It supports a set of commands defined intsserverlibrary.d.ts.typescript-language-serverwrapstsserverfor LSP editors. It translates LSP requests intotsservercommands and back. This is how Neovim, Emacs, Sublime Text, and Helix get TypeScript support .- VS Code does not use the LSP for TypeScript. It uses
tsserverdirectly through thetypescript-language-featuresextension. This is why VS Code’s TypeScript support is richer and more responsive than editors that use the wrapper . - TypeScript 7.0 adds native LSP support. The Go-based compiler includes an LSP server. VS Code has a dedicated extension. The community wrapper may become unnecessary. The performance gains are significant: 8xโ12x on full builds, and sub-1.3-second file opens in the VS Code codebase .
- The workspace TypeScript version can be selected in VS Code. The
js/ts.tsdk.pathsetting points tonode_modules/typescript/lib. Thejs/ts.tsdk.promptToUseWorkspaceVersionsetting controls the confirmation prompt. This ensures the editor uses the same TypeScript version as the project . - Language service plugins extend
tsserver. They are registered intsconfig.jsonundercompilerOptions.plugins. They receive the language service and can proxy its methods to modify completions, refactorings, and diagnostics .
Remember: The Language Server Protocol is the interface that decouples editors from language implementations. TypeScript’s tsserver was the foundation of the LSP, and it remains the server that VS Code uses directly. Other editors use the typescript-language-server wrapper to translate LSP requests into tsserver commands. TypeScript 7.0 changes this by adding native LSP support to the Go-based compiler, which may eventually replace the wrapper. The protocol is the contract; the server is the implementation. Understanding both explains how your editor knows what it knows.
Stop using slow, ad-bloated tool sites! ๐คฎ
๐ Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
โ
Finance (Mortgage, Interest, Inflation)
โ
Tech (Base64, JSON, Dev Suite, IP)
โ
Health (BMI, BMR, TDEE)
โ
Productivity (Timer, Workspace, QR)
โก๏ธ Fast & Private
๐ No data leaves your device
๐ 100% Free
๐ Use it now: https://tools.kandz.me
๐ Bookmark itโyouโll need it later!