Editor support
Varar ships an editor integration so that an oath — plain Markdown that happens to be executable — reads and edits like real code: matched steps are highlighted, you can jump from a sentence to the function that runs it, and the editor tells you when a paragraph has stopped being an example. It comes in two pieces:
@varar/lsp— a standalone Language Server Protocol server. It holds all the intelligence: parsing, step matching, diagnostics, snippet generation, and rename planning. Because it speaks LSP, any editor with an LSP client can drive it.- The Varar VS Code extension (
varar.varar) — a thin client that bundles the language server and wires its features into VS Code menus, commands, and the editor surface.
Everything on this page is powered by the language server, so an editor other
than VS Code that points an LSP client at varar-lsp gets the same feature set.
Install
Section titled “Install”The extension is published to the Open VSX Registry, so it installs in VS Code and every VS Code–compatible editor — VSCodium, Cursor, Windsurf — that resolves extensions from Open VSX:
- In-editor: open the Extensions view, search for Varar, and install
varar.varar. - From the CLI:
code --install-extension varar.varar(or the equivalentcodium/cursorcommand).
The extension activates when a workspace contains a varar.config.json, or when
you open a Markdown, TypeScript, Python, Java, or Kotlin file. It needs that
config to know which files are oaths and where your step definitions live — see
the Examples reference for the docs globs that decide
what counts as an oath.
Feature set
Section titled “Feature set”The features below work in any oath (.md) and its step-definition files.
Step definitions are supported in TypeScript, Python, Java, Kotlin, and
Ruby — the language server carries a tree-sitter grammar for each, so
matching, go-to-definition, and rename cross the Markdown ↔ code boundary in
whichever language your steps are written.
Matched-step highlighting
Section titled “Matched-step highlighting”The editor colours the sentences in an oath that actually match a registered stimulus or sensor, and the parameter spans within them, using semantic tokens. Prose that matches nothing stays plain. At a glance you can see which paragraphs are executable examples and which are narration — and a step you expected to be live but that reads as plain prose is instantly visible.
Go-to step definition
Section titled “Go-to step definition”Invoke Go to Definition on a matched sentence and the editor jumps to the
stimulus() / sensor() call that runs it, in the step-definition file, in any
supported language. It also works in reverse from the step-definition
expression.
Hovering a matched step surfaces details about the step it resolves to — the binding behind the sentence — without leaving the oath.
Completion
Section titled “Completion”As you write a sentence in an oath, completion offers the registered steps that could match, so you can author against the vocabulary your step definitions already provide instead of guessing at wording.
Diagnostics
Section titled “Diagnostics”The server publishes diagnostics into the editor’s Problems panel and inline
squiggles. Beyond parse errors, it ingests the results of the last run (the
.varar/*.json files the runner writes) and reflects them back onto the source:
- Drift — a paragraph that used to be an example and now matches nothing. This is the dangerous case Varar refuses to let pass silently; see Drift detection.
- Missing steps — a sentence that looks like it should run but has no matching step definition.
- Cell mismatches — when a sensor’s returned value disagrees with the Markdown, the diff is anchored to the exact source span, so the failing cell or doc-string line is reddened in place.
Accept as prose (drift quick-fix)
Section titled “Accept as prose (drift quick-fix)”Drift is held until you acknowledge it. On a drift diagnostic the editor offers an Accept as prose quick-fix: confirming that a paragraph is intentionally no longer an example records the new baseline — the editor equivalent of acknowledging the drift in the runner.
Generate Step Definition from selection
Section titled “Generate Step Definition from selection”Select a sentence in an oath and run BDD: Generate Step Definition from Selection — from the context menu, the Command Palette, or as a refactor action. The server generates a step-definition snippet for the selection (with a parameter for each captured value), you pick which steps file to add it to, and the extension appends it. This is the fast path from an unbound sentence to a working step.
Cross-file Rename
Section titled “Cross-file Rename”Press F2 on a matched step — either on the sentence in the Markdown or on the
stimulus() / sensor() expression in a steps file — and Varar renames the step
everywhere at once: it rewrites the step-definition expression and its handler,
and re-renders every matching sentence across every oath to the new wording. If
the new form adds a parameter or changes a parameter’s type, the editor prompts
for the value each affected example should use, so the oaths stay runnable
through the rename.
Using the language server in other editors
Section titled “Using the language server in other editors”@varar/lsp is a plain LSP server with a varar-lsp executable. Any editor
that can launch a language server for Markdown and your step-definition files can
consume it directly and get the same highlighting, navigation, diagnostics, and
rename features described above — the VS Code extension is just the reference
client.