LSP SDK
The LSP SDK provides target-aware Language Server Protocol integration. Unlike traditional LSP setups that configure paths globally, RBS resolves dependencies per-target — your editor’s autocomplete, go-to-definition, and diagnostics reflect only the dependencies your specific target can actually import.Why target-aware LSP?
Traditional LSP setups give you completions for every package installed on your system. RBS does it differently:| Traditional LSP | RBS LSP | |
|---|---|---|
| Scope | All installed packages | Only your target’s declared deps |
| Accuracy | May suggest unrelated packages | Only suggests what you can actually import |
| Consistency | Varies by developer machine | Same results for everyone (hermetic) |
| Configuration | Manual path setup | Automatic from build graph |
How it works
- You open a file — e.g.,
src/main.pyin your editor. - RBS resolves the target — determines that
src/main.pybelongs to//src:app. - Dependencies are analyzed —
//src:appdeclaresdeps = ["@pip//requests", "@pip//flask", ":utils"]. - Paths are resolved — dependencies map to filesystem paths in
.rbs/external-deps/. - LSP is configured — the language server receives only the relevant paths.
- You get accurate completions — autocomplete suggests
requestsandflask, but not unrelated packages.
Quick start
1. Load a built-in provider
In yourWORKSPACE.rbs:
2. Sync dependencies
3. Connect your editor
Your editor connects to the LSP through the RBS server automatically when you open files. If you’re building a custom integration, connect via:- WebSocket:
ws://your-server/ws/lsp/{language} - REST API:
http://your-server/api/lsp/*
Built-in providers
Python
- Server: python-lsp-server (pylsp)
- Extensions:
.py,.pyi - Features: Jedi-based completion, rope refactoring, pyflakes linting
TypeScript / JavaScript
- Server: typescript-language-server
- Extensions:
.ts,.tsx,.js,.jsx,.mjs,.cjs - Features: Full TypeScript/JavaScript support with type checking
Go
- Server: gopls
- Extensions:
.go - Features: Official Go language server with full LSP support
Creating custom LSP providers
The SDK-first design means you can define LSP support for any language through configuration:Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
name | string | Yes | Provider name. |
language | string | Yes | Language identifier. |
file_extensions | list | Yes | File extensions to handle. |
server | string | Yes | Server binary reference. |
server_args | list | No | Arguments passed to the server. |
resolve_paths | string | No | RBS DSL function to resolve dependency paths. |
initialization_options | dict | No | LSP initialization options sent to the server. |
root_markers | list | No | Files that indicate the project root. |
Server references
Theserver parameter supports multiple formats:
Path resolution function
Theresolve_paths function receives a context object with access to the target’s build graph:
Initialization options
Use${RESOLVED_PATHS} as a placeholder that will be replaced with the resolved dependency paths:
REST API
List providers
Get a provider
List running servers
Start / stop a server
Resolve a file to its target
Find which target a file belongs to and what dependency paths are resolved:WebSocket protocol
Connect
Open a file (triggers path resolution)
LSP requests/responses
Standard JSON-RPC 2.0 LSP messages are proxied through the WebSocket:Editor SDK integration
- TypeScript
- cURL
Troubleshooting
No completions
- Run
rbs sync //your:targetto ensure dependencies are downloaded. - Verify the file belongs to a target with declared
deps. - Check that paths are resolved:
POST /api/lsp/resolvewith your file path.