lemonxiny55/dsh-lsp-diagnostics

dsh-lsp-diagnostics

English | 中文

Real-time compiler/LSP diagnostics — a DeepSeek Harness (dsh) plugin that closes the edit → diagnostics → fix loop: the model edits a file, immediately sees what broke (file:line:col + code + message), and fixes it. This is Cursor's killer feature, for dsh agents.

What the model gets

Plus an optional auto-injected system prompt section (lsp:diagnostics, order 70): after the model writes/edits a file through the harness, the plugin subscribes to the fs/observed event, refreshes the file on its language server, and injects only the new/changed diagnostics introduced by that edit — never the whole workspace. Stale deltas expire (sectionTtlMs, default 30s). Set autoInject: false to disable and rely on the tools only.

The loop

model edits file  ──►  dsh writes it (fs tool)
                        │
                        ▼ fs/observed event
        plugin refreshes the file on its LSP server
                        │
                        ▼ publishDiagnostics
        delta injected into the prompt (or lsp_diagnostics on demand)
                        │
                        ▼
        model reads "src/a.ts:12:3 error TS2322 …"  ──►  fixes it

Install

Requires dsh (any install path — npx, npm, or source), Node ≥ 22, and the LSP servers on PATH:

npm i -g typescript-language-server typescript
npm i -g pyright

Both servers are npm-installable — no Python runtime, no native binaries.

# from npm (prebuilt)
npx @deepseek-ai/dsh plugin --profile web add dsh-lsp-diagnostics

# or from a directory containing this checkout
npx @deepseek-ai/dsh plugin --profile web add ./dsh-lsp-diagnostics

Restart the Web UI (npx @deepseek-ai/dsh web) — startup logs confirm each tool:

[dsh-lsp-diagnostics] plugin loaded
[dsh-lsp-diagnostics] registered tool: lsp_diagnostics
...

Missing a server? The tools say so, with the exact install command: LSP server "pyright-langserver" is not installed or failed to start. Install it with: npm i -g pyright.

Using it

In a workspace session, ask the agent:

• "Edit src/extract.ts to split out the parser, then check it with lsp_diagnostics."
• "What's currently broken in the workspace?" (lsp_workspace_errors)
• "What type is code at line 121?" (lsp_hover)

Example (input → output):

lsp_diagnostics { file: "src/extract.ts" }
# diagnostics (3 errors, 1 warning)
src/extract.ts:121:10  error  TS2304  Cannot find name 'foo'
src/extract.ts:144:3   error  TS2322  Type 'string' is not assignable to 'number'
src/store.ts:8:5       warn   TS6133  'x' is declared but never used

The canonical JSON (severity, range, code, message, source) is what execute returns; the compact table above is the rendered view.

Configuration

Options are passed as the plugin row's config in the profile patch (or defaults are used if absent):

# $DSH_HOME/profiles/<name>/cordis.patch.yml — a bare row overrides by id.
- id: lsp-diagnostics
  config:
    maxDiagnostics: 30
    autoInject: true

Supported languages

• TypeScript / JavaScript via typescript-language-server (.ts .tsx .mts .cts .js .jsx .mjs .cjs)
• Python via pyright-langserver (.py .pyi)

Rust (rust-analyzer is a native binary) is deliberately deferred — servers.ts is the seam where further servers plug in (command, args, install hint).

How it works

• LSP clients (src/lspClient.ts): one headless JSON-RPC client over stdio per server process, built on vscode-languageserver-protocol + vscode-jsonrpc only (no VS Code bits). initialize/initialized handshake → full-text didOpen/didChange sync → publishDiagnostics subscription → clean shutdown/exit/kill teardown.
• Lifecycle (src/manager.ts): one server per (workspace root, language), spawned lazily on first use. A crashed server is restarted once (its open documents are replayed); a second crash marks the language degraded with a clear message instead of a respawn loop. Plugin unload kills every spawned server (verified by a lifecycle test).
• Edit detection (src/section.ts): subscribes to the harness fs/observed event (fired by @deepseek-ai/dsh-tool-fs after read/write/edit commit). The listener only queues the file (sync, never throws); a debounced refresh diffs the fresh diagnostics against the previous state per file and renders the delta.
• Workspace resolution: session cwd → walk up to the nearest .git (bounded), same as dsh-code-index. Files outside a repo are refused.
• Token-cost awareness: every surface — tool output and injected section — is capped by maxDiagnostics; the injected view is a per-edit delta, not the workspace.

Known limitations

• lsp_workspace_errors covers files the servers have seen this session (a file joins the set the first time lsp_diagnostics checks it) — standard LSP open-file semantics, not a whole-repo batch scan.
• TypeScript 7 (the native/Go port) has no lib/tsserver.js; keep typescript@5 resolvable in the workspace (typescript-language-server falls back to its own bundled 5.x when the workspace doesn't pin one).
• Auto-injection triggers on harness file events; direct out-of-band edits (the user editing files externally) are not observed until the tool is called.
• Servers must be on PATH (or overridden via serverPath); no servers are bundled, by design.
• Developer-preview harness: expect breaking harness/plugin API changes upstream.

Development

pnpm install
pnpm test        # vitest — client handshake/mapping/tools/lifecycle against a fake LSP server
pnpm typecheck
pnpm build       # tsup → dist/index.js (ESM, external deps)

The suite runs against tests/helpers/fakeLspServer.mjs — a minimal stdio LSP server that derives diagnostics from // diag: <severity> <code> <message> markers — so no real pyright/tsserver is needed in CI.

Feedback

Found a bug, or a server/language you want next? Please open an issue.

License

MIT. Not affiliated with DeepSeek; built on the public dsh plugin surface.