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.

One setting, NexusFabric › Libs (nexusFabric.libs): the directory of shared .flow.md files, as nexus validate --libs, relative to the workspace folder or absolute. It is empty by default, so a flow that includes a library shows the same refusal nexus validate prints without --libs; set it to your library directory, for example lib, and the refusal goes. The extension passes it to the language server at start and on every change; see the language server for what the server does with it.

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). A last section, Other keys, shows every other front-matter key the platform reads, and every other VFS and JMS connector key, as a text field labelled with the key name: config, routes, inbound, trigger_extensions, trigger_tls_ca_cert and the rest. A field holds the value as the file writes it, quotes and brackets included, and is written back as typed; clearing it removes the key from the file. The panel does not check these values. nexus validate refuses a value of a platform key that it cannot read, such as a routes entry that is not METHOD /template or a config name that is not an identifier, and the language server shows the same refusal as you type; a value it can read, such as the text of method, is accepted as written. Neither checks a connector key: the connector does, when it starts (see VFS and JMS). Trigger type shows the file’s trigger: value as written: a value other than vfs or jms (ftp, JMS, a quoted "jms") appears as its own option and is saved unchanged, and so is every VFS and JMS field the file sets, whatever the trigger. A file without trigger: is saved without one, even when connector fields are filled in.
  • 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.