HelixFlo

Snippets, real-time validation, and one-click deploy for HelixFlo projects, right in VS Code.

What this gives you

• Snippets for every flow step type (log, var, transform, http-call, db-query, file, respond, class, script, if, switch, for, try, goto, async, sequence, plus every publish connector: redis-publish, redis-list-publish, redis-stream-publish, rabbitmq-publish, kafka-publish), and skeletons for whole files (apis/*.yaml, inbound/*.yaml per type, sequences/*.yaml, project.yaml, datasources.yaml, globals.yaml). Type an mi- prefix in any .yaml file and pick from the suggestions. There's also an mi-connector snippet for connectors/*.java files - a Mediator class skeleton (class name pre-filled from the file's own name, since the server requires them to match) ready to compile server-side on deploy.
• Validation - red squiggles for a misspelled step name, a missing required field (e.g. a redis step without op), or a wrong type - as you type, via JSON Schema, not a custom language server. Autocomplete and hover docs for field names come along for free from the same schemas. On top of that, HelixFlo also flags duplicate api/sequence names within a project - if two files under apis/ (or two under sequences/) declare the same name:, the server can't tell them apart (it addresses both by that name, not the filename), so both files get an error in the Problems panel until you rename one.
• HelixFlo: New Project (Command Palette) - scaffolds a new project: project.yaml, empty datasources.yaml/globals.yaml, empty inbound//sequences//scripts//connectors/ directories, and one working apis/hello-world.yaml so there's something to deploy right away.
• HelixFlo: New Connector Class - right-click a project's connectors/ folder in the Explorer, name the class, and get a {ClassName}.java file with the Mediator skeleton already filled in (the same shape as the mi-connector snippet), cursor placed inside mediate() ready to edit.
• Deploy straight from VS Code, no need to switch to a terminal or the admin UI:

  • Right-click a project folder (the one with project.yaml) in the Explorer → HelixFlo: Deploy Project - zips it and does a full redeploy via POST /mgmt/projects, same as uploading a .zip through the admin UI.

  • Right-click that same folder → HelixFlo: Build Project (.flo) to produce a standalone .flo package (a plain zip - project.yaml at its root, same as above) on disk instead of deploying immediately, for archiving or handing off. Right-click any .flo file later → HelixFlo: Deploy .flo File to deploy it exactly the way Deploy Project would.

  • Right-click a single file - either in the Explorer or from inside the editor itself (right-click in the text, or the deploy icon in the editor's tab toolbar) → HelixFlo: Deploy This File. The extension finds the project by walking up from the file to the nearest project.yaml and reading its project.name, then picks the right update based on the file:

    • A file inside apis/, inbound/, or sequences/ - replaces just that one resource on an already-deployed project, without redeploying everything else.
    • A .js file inside scripts/ - uploads/replaces that script by filename.
    • A .java or .jar file inside connectors/ - uploads that connector; a .java file is compiled server-side, a .jar is used as-is. Any api/inbound/sequence that was already deployed keeps using the old compiled class until its own project is redeployed (ordinary Java classloading - a fresh class isn't picked up by code that already resolved the old one), so a connector-only deploy also offers a Redeploy Project follow-up to make the change actually take effect.
    • datasources.yaml or globals.yaml at the project's root - replaces that whole file (these are singleton files server-side, so the update is always a full-file replace).
    • project.yaml - there's no single-file update for the manifest itself, so this instead triggers the same full project redeploy as HelixFlo: Deploy Project, with a message explaining why.

    If the file is open in an editor, whatever's currently in the buffer is what gets deployed - including unsaved edits or a brand-new file you just typed into, not whatever's (or isn't) on disk yet.

    Every one of these single-file routes needs the project to already exist on the server - for a brand-new project (e.g. right after HelixFlo: New Project), deploying its first file this way fails with "hasn't been deployed yet". HelixFlo catches that specific case and offers a Deploy Project button right there instead of making you switch commands.

  • HelixFlo: List Deployed Projects (Command Palette) - a quick reachability check plus a look at what's currently deployed on the configured admin API.

• Browse, download, and diff what's actually deployed - a "HelixFlo: Deployed Projects" view in the Explorer sidebar (similar to the Salesforce extension's org browser), populated straight from the admin API, independent of whatever's open locally:
  • Lists every deployed project on load. Expand one to see its apis/inbound/sequences/ scripts/connectors and its project.yaml/datasources.yaml/globals.yaml. Use the refresh icon in the view's title bar to re-sync after deploying from elsewhere.
  • Right-click a project → HelixFlo: Download Project - downloads it as a zip (the same GET /mgmt/projects/{project} the admin UI uses) and extracts it into a folder you pick.
  • Right-click a file → HelixFlo: Download File - downloads just that one file. If the project's already open in your workspace (matched by project.yaml's project.name), it's written straight into the right spot, overwriting whatever's already there - so this doubles as "refresh this file from the server" for a file you already have locally. Otherwise you're prompted for where to save it.
  • Right-click a local file - in the Explorer or the editor - and choose HelixFlo: Compare with Server to open a diff between what's on disk and what's currently deployed. Works for apis/, inbound/, sequences/, scripts/*.js, project.yaml, datasources.yaml, and globals.yaml (not connectors/*.jar - there's nothing meaningful to diff in a binary jar).
  • Click any API in this view (it's the only file kind with the beaker icon) to open it straight in the API Tester - see below.

API Tester

A Postman-style panel for calling a deployed API without leaving VS Code - a method/URL bar with color-coded verbs (GET green, POST blue, PUT orange, PATCH purple, DELETE red), Params/Headers/Body tabs for the request, and a response panel with a color-coded status badge, timing, size, and a syntax-highlighted body.

• Click an API in the "HelixFlo: Deployed Projects" view (or right-click it → HelixFlo: Test API) - fetches its YAML from the server, and if it defines more than one resource, asks which one (e.g. GET /orders/{id} vs POST /orders) before opening the tester prefilled with the right method and URL.
• Right-click a local apis/*.yaml file - in the Explorer, the editor, or the beaker icon in the editor's tab toolbar - to do the same thing against a file you have open, without it needing to already be in the remote tree.
• HelixFlo: Test API from the Command Palette opens a blank request if there's no API file in context.

Request history - a sidebar lists your last 25 requests (method, path, status, relative time), persisted across VS Code restarts. Click one to reload its method/URL/headers/body back into the request bar - nothing re-sends automatically, you still control when a request actually goes out. Params are kept in sync with the URL's query string in both directions - edit a param row and the URL updates, or paste/type a URL with ?a=1&b=2 and it's parsed into rows automatically. Copy the response body with one click, or read its size and timing at a glance next to the status badge.

The tester reuses a single panel across invocations - testing another API reveals the existing panel and updates its prefill rather than opening a new tab each time. Every response is shown exactly as the server sent it, including 4xx/5xx status codes - this is a test client, not something that treats a non-2xx response as a failure to report instead of data to show you.

Configuration

There's no authentication here because the admin API itself doesn't have any today - if you're pointing this at anything other than localhost, make sure that's a network you actually trust.

How it works

This extension ships JSON Schemas for each HelixFlo file type and registers them with the YAML extension (a dependency, installed automatically) via its yamlValidation contribution point. There's no custom language server here - schema-based validation catches structural mistakes (wrong types, missing required fields, unknown step names) but not cross-file semantics (e.g. a sequence step naming a sequence file that doesn't actually exist, or a class step naming a connector that was never uploaded).

Installing (unpublished / local use)

cd vscode-extension
npm install -g @vscode/vsce   # if you don't already have it
vsce package
code --install-extension helixflo-vscode-0.0.1.vsix

File types covered

api-definition.schema.json, inbound-definition.schema.json, and sequence-definition.schema.json all reference the shared step-type definitions in schemas/step.schema.json, since a mediator step (log, var, transform, ...) can appear inside any of the three (an API resource's flow, an inbound listener's flow, or a sequence's flow).