Skip to content
NexusFabric

The VS Code extensions

Two separate extensions, each with its own .vsix — not one extension with two features. Both declare the same flowmarkdown language and the same syntax highlighting for .flow.md, so either one on its own gets you highlighting; install both for the full set below.

Installing

Both extensions ship built, in the delivery bundle, next to the nexus-lsp binary and the script that installs all three:

Terminal window
$ ./install.sh
installed nexus-flowmd-lsp-0.1.2.vsix
installed nexusfabric-flow-editor-0.1.52.vsix
installed nexus-lsp into /home/you/.local/bin

The script installs whatever of the three it finds beside it, says what it did, and exits non-zero when something it tried could not be installed. It downloads nothing and compiles nothing. Two options change where things land: --bin-dir DIR for the language-server binary (default ~/.local/bin, which has to be on your PATH or VS Code will not find it), and --code CMD when your VS Code command line is not code.

Without the script, each .vsix installs through Extensions → Install from VSIX, or with code --install-extension <file>.vsix, and nexus-lsp goes anywhere on your PATH.

VS Code LSP extension

Package nexus-flowmd-lsp, displayed as NexusFabric FlowMarkdown.

The text-editing side. It launches the nexus-lsp binary and wires it into VS Code as a language client, so opening a .flow.md file gets you the diagnostics, completion and hover described on the language server page, live as you type. The command it runs is fixed to nexus-lsp looked up on your PATH — there is no server-path setting to point elsewhere. install.sh puts the binary there; without it the extension loads but reports no diagnostics.

VS Code Visual extension

Package nexusfabric-flow-editor, displayed as NexusFabric Flow Editor.

An alternative editor for the same .flow.md file — not the default. Right-click the file and choose Reopen Editor With… → Flow Visual Editor, or click the Source button at any time to switch back to plain text. Both views edit the same file: a change made on the canvas is written back as FlowMarkdown immediately, and a change made in the text editor is reflected on the canvas just as fast.

Layout:

  • A toolbar button showing the flow’s name and tenant — click it to open Flow Settings, the front matter: flow name, tenant, global effects, schedule, required scope, the VFS/JMS trigger fields, queue retry settings, and logging settings (log_level and the rest).
  • The canvas itself, one node per step, in order. Click a node to edit that step in the sidebar instead: its name, body type, the fence content itself, HTTP effect fields (effects, endpoint, method, content_type, timeouts), and save_body/restore_body. From there you can also reorder the step, duplicate it, or delete it (with a confirmation).
  • A + between or after nodes opens a picker for the step’s kind — Condition, Validate, NTD, XSLT, Route, Foreach, Split, Fork, Call Flow, or a plain step with no body — each with a one-line description and a sensible starting template.
  • Steps that reference another flow (call_flow, foreach, split, fork) can jump straight to that flow’s own canvas. The target is resolved the way nexus deploy resolves it: by the flow: front-matter field — not the file name — and within the calling flow’s tenant. If the name exists in the workspace only under another tenant, the jump is declined with a note, because deploy would refuse that reference too (a call_flow name is not a cross-tenant reference). If several files under the same tenant declare the name, you are asked which one to open.

Diagnostics on the canvas — the warning or error badge on the Flow Settings button and on individual step nodes — are not produced by this extension. They are whatever VS Code already has published for the open document, which is only there if the VS Code LSP extension above is also installed. The visual extension does not launch nexus-lsp itself; without the other extension, the canvas shows no diagnostics at all.