3.8 KiB
VS Code / Positron Extension — Exploration
Point-in-time memo, 2026-07-04. Option recorded for post-1.0; nothing is being built. Assesses shipping Astrolabe's authoring intelligence as an editor extension.
The idea
Port the editor-intelligence layer — scaffolding CodeLenses, spec-aware completions, the
data inspector, live preview — to a VS Code extension (and Positron via OpenVSX), working
on .vl.json files in the user's own workspace.
Why it's cheap: the core/adapter boundary
Everything interesting is already editor-agnostic. src/core/ (spec analysis, scaffold
construction, site detection over JSON offsets, rendering preparation) has no Monaco
imports; the Monaco layer (spec-param-scaffold, spec-transform-scaffold,
editor-cursor-lens) is thin adapters. VS Code's extension API has one-to-one
counterparts:
| Astrolabe piece | VS Code counterpart |
|---|---|
| CodeLens scaffolds | languages.registerCodeLensProvider + core verbatim |
| Param/transform completions | registerCompletionItemProvider / code actions |
Live preview (chart-renderer) |
Webview panel running vega-embed (same browser ctx) |
Data inspector (inspectData) |
Same webview, message bridge to the render handle |
| Bundled schema (offline) | jsonValidation contribution |
Dataset-by-name (data.name) |
Resolve against a workspace datasets/ folder |
Both editors expose offset↔position conversion, so the core's offset-based site detection transfers without change.
The marketplace gap
Preview exists; authoring help does not.
- Vega Viewer and Vega Preview render specs — preview-only.
- The official vega plugin is deprecated; its note
points out VS Code's built-in JSON service already gives
$schema-driven completion and validation. Schema completion/validation are therefore table stakes in VS Code, not differentiators — unlike on the web, where Astrolabe had to build them. - Nothing in the marketplace offers scaffolds, an input-vs-resolved data inspector, dataset references, or theme configs.
Positron (Posit's VS Code fork, OpenVSX-distributed) concentrates the Altair audience — people whose wrapper output is already Vega-Lite and who live in an editor. For them an extension is more native than any website.
v1 scope, if built
In: bundled-schema validation (offline), scaffold CodeLenses (params/transforms), live
preview panel, data inspector, data.name resolution against a workspace folder, theme
as an apply-able config file. Out, deliberately: the library, drafts/publish (git covers
it), the chart builder UI, the theme builder, fonts UI. The extension is "Astrolabe's
authoring intelligence, detached" — the home identity does not port, because in an
editor the workspace already is the home.
Strategic read
For: real organic discovery (people search "vega" in the marketplace; nobody web-searches for a snippet manager they don't know exists); every extension user is a lead for the app; the port validates the core-first architecture.
Against: a second product surface for a single maintainer; it showcases the commodity part of Astrolabe (editing) rather than the unique part (the home); Positron/OpenVSX publishing is an extra channel to maintain.
Decision: defer until after the web app's 1.0. The only standing cost of keeping the
option open is one we already pay by conviction: keep src/core/ free of editor and
browser imports.