DefLang VS Code Extension

Syntax highlighting and live diagnostics for .def files (DefLang, see the repo root README).

Two pieces: a declarative TextMate grammar for highlighting (no build step), and a small TypeScript client that spawns def lsp as a child process and talks LSP over stdio to get live-as-you-type diagnostics (same checks as def check, just running continuously).

Files

• package.json — the extension manifest. Registers the def language id for the .def extension, points VS Code at the grammar/language configuration below, declares the def.serverPath setting, and wires up out/extension.js as the extension's entry point.
• language-configuration.json — non-highlighting editor behavior: // line comments, bracket pairs, and auto-closing/surrounding pairs for (), [], {}, ".
• syntaxes/def.tmLanguage.json — the TextMate grammar that does the actual highlighting. Rules are matched in the order listed under patterns; when two rules could match at the same position (e.g. integer( looking like both a type and a function call), the earlier one in the list wins. Notable choices:
  • def NAME is matched as one unit (variable-declaration) so the declared name is colored distinctly, ahead of the plain def keyword rule.
  • NAME as TYPE (parameter-declaration) covers function parameters like a as integer.
  • Double-quoted and triple-quoted ("""...""") strings both support {{expr}} interpolation via a shared interpolation rule.
  • Bare all-caps words (GET, POST, READ, ...) are highlighted as language constants since the lexer treats them as plain identifiers, not reserved words.
• src/extension.ts — the language client. Reads def.serverPath (default def, found on PATH), spawns <serverPath> lsp via vscode-languageclient, and starts/stops it on activate/deactivate. Compiles to out/extension.js (see tsconfig.json).
• samples/demo.def — a scratch file covering most language constructs (types, const, functions, if/match, for, mocks, requests) to eyeball the highlighting/diagnostics against.
• .vscode/tasks.json + .vscode/launch.json — F5 runs the npm: compile build task first, then opens an Extension Development Host with the extension loaded.

Building the client

npm install
npm run compile   # or: npm run watch

Needed once before F5 works (and again after editing src/extension.ts if not using watch; launch.json's preLaunchTask already runs compile automatically on every F5).

Try it

1. cd vscode-extension && npm install && npm run compile
2. Build the server: from the repo root, cargo build (produces target/debug/def).
3. Open this vscode-extension/ folder directly in VS Code (not the repo root).
4. If def isn't on your PATH yet (e.g. you haven't run cargo install --path ..), set def.serverPath to the absolute path of target/debug/def — either in this workspace's settings, or in .vscode/settings.json of whatever workspace you'll open the Extension Development Host onto.
5. Press F5 (or Run > Start Debugging). A new "Extension Development Host" window opens.
6. In that window, open samples/demo.def (or any file from ../examples) and confirm highlighting looks right and no diagnostics appear on a clean file.
7. Introduce a syntax error (e.g. remove a closing paren) and confirm a squiggle appears within about a third of a second; fix it and confirm the squiggle clears.
8. Edit syntaxes/def.tmLanguage.json and reload the dev host window (Cmd/Ctrl+R or "Developer: Reload Window") to see grammar changes — no rebuild needed. Changes to src/extension.ts need npm run compile (or watch) plus a reload.

Known scope limits (by design, for v1)

• Only .def is registered. The sidecar template files (.hdef, .qdef, .jdef, .tdef, .edef, .fdef) aren't full DefLang syntax — they're plain header/JSON/text/env content with {{var}} substitution, so they need their own (much simpler) grammar later rather than reusing this one.
• Diagnostics only — no hover, completion, or go-to-definition yet.
• No equivalent of --param KEY=VALUE: the language server always checks with an empty params map, so a script relying on from_cmd_param may show a diagnostic in the editor that def check --param ... from the CLI wouldn't.
• Changing def.serverPath requires reloading the window — the client doesn't watch for configuration changes and restart itself.
• Diagnostic ranges cover the whole reported line (there's no column information in DefLang's lexer/parser today), and only one diagnostic is ever shown at a time — the underlying pipeline stops at the first error, same as def check from the CLI.