Files
astrolabe/docs/exploration/vscode-extension.md
T

72 lines
3.8 KiB
Markdown

# 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](https://marketplace.visualstudio.com/items?itemName=RandomFractalsInc.vscode-vega-viewer)
and [Vega Preview](https://marketplace.visualstudio.com/items?itemName=mdk.vega-preview)
render specs — preview-only.
- The [official vega plugin](https://github.com/vega/vega-vscode) 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.