Workman VS Code Extension

Small VS Code client for Workman. The Marketplace package includes one portable JavaScript language server bundle that runs on VS Code's built-in Node runtime, so the same small VSIX supports Linux, Windows, and macOS on every architecture supported by VS Code. By default the extension prefers the system wm lsp command: it probes wm from PATH and uses it whenever the command launches and exits cleanly. On development machines wm itself runs the Workman checkout, so wm lsp already serves frontend and LSP changes after Workman: Restart Language Server. When the probe fails, the extension falls back to the packaged server bundle.

The packaged server does not need Deno for ordinary Workman files. JavaScript/TypeScript FFI reflection still uses the deno executable configured by workman.denoPath (default: deno).

C header reflection automatically uses a packaged Aro binary on Linux, macOS, and Windows for x64 and ARM64. No Zig installation is required. The matching binary, resource headers and licenses are unpacked into a local cache on first use; system C headers/SDKs remain necessary. WM_C_HEADER_EXTRACTOR overrides the packaged executable; WM_C_HEADER_BACKEND=zig selects the previous system-Zig backend. See the extractor docs for cache configuration and beta limitations.

Extension builds use the Go-native TypeScript 7 compiler. The bundled FFI reflector intentionally uses the separately named TypeScript 6 compatibility API because TypeScript 7.0 has no programmatic compiler API; migrate reflection when the new API arrives in TypeScript 7.1 rather than silently falling back from tsc 7 during builds.

Language features

• Syntax highlighting for character literals, primed identifiers, nested block comments, numeric exponents, Unicode escapes, and string gaps. Word selection includes trailing identifier primes.

• Module-aware diagnostics and inferred-type hover, including unsaved Workman files. Annotated bindings also show unannotated: when removing their annotations infers a different type.

• Go to Definition/Ctrl+Click for local bindings, types, constructors, and named, wildcard, or namespace imports.

• Find All References across the active module graph and other open Workman documents.

• Document symbols for the Outline and Go to Symbol views.

• Automatic cleanup and dependent revalidation when .wm files are deleted, renamed, or moved.

The wm lsp server runs under deno run -A via the wm launcher. Environment access is needed because the language server uses TypeScript's compiler API for JS FFI type reflection. Run access is needed when reflecting the Deno global namespace, which mounts deno types as the source of Deno's own declarations.

Development

npm install
npm run compile

Open this folder as a VS Code extension development host, or package it later as a VSIX. The included Run Workman Extension launch config opens the repository root as the test workspace.

Marketplace package

Create the universal VSIX from this directory:

npm run package

This bundles the extension client and language server with esbuild and writes dist/goodpuppies.workman-<version>.vsix. The package contains no native runtime or platform-specific binary; the current bundle is about 1.8 MiB including TypeScript's standard-library declarations for FFI reflection. Upload that file through the Visual Studio Marketplace publisher portal.

By default the extension probes wm lsp from PATH and falls back to the bundled server. To force a specific server, set workman.serverPath to a wm launcher executable/script (launched as wm lsp; usually just a script running deno run -A main.ts) or a compiled JavaScript server bundle:

{
  "workman.serverPath": "/absolute/path/to/wm"
}

There is no source-checkout mode: on development machines wm runs the checkout, so point workman.serverPath at wm itself when the launcher is not on PATH. Then updates to the Workman checkout usually only need Workman: Restart Language Server.

Generated frontend

The language server always uses the generated frontend-v2 runtime included in the repository and extension package. To reproduce it from the Workman sources:

deno task frontend-v2:build

By default the server loads src/generated/frontend_v2_parser.js from the checkout or package that provides the running server. To point at another generated artifact, set:

{
  "workman.frontendV2ModulePath": "/absolute/path/to/frontend-v2.generated.mjs"
}

This is a real semantic frontend mode, not a structural sidecar: frontend v2 is the parser feeding module loading, typechecking diagnostics, and hover. Generated Surface-to-compiler lowering matches Peggy semantic fields and source spans across every valid .wm file under std, examples, and tooling.

Frontend v2 renders committed missing ;, {, and } marks as structural inlay hints. Other malformed input receives the generated parser's farthest-failure diagnostic; the retired transitional _/? hole projection is not part of this mode. Disable structural hints independently with workman.structuralInlayHints.enabled and restart the language server.