Skip to content

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.

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 equivalent codium / cursor command).

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.

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.

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.

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.

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.

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.

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.

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.

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.