Targ Apps Docs
Chroma

Editor & CLI tooling

How the VS Code extension, linter, and Chroma CLI relate to Portable (Web) vs Executable (Chroma Desktop) — project-side, not runtime hosts.

The VS Code extension (targapps.chroma), @chroma/linter, and chroma CLI run on your development machine. They do not execute inside Portable or Executable runtimes and do not model host differences in diagnostics today.

Use Runtime modes and browser plugins by mode when you need mode-specific behavior. Use this page for what the toolchain validates regardless of where you deploy.

Compatibility matrix

ToolPortable targetExecutable targetWhat it knows about modes
VS Code extensionFull (project lint)Full (project lint)Reads dev.desktop only indirectly via chroma.json schema; no "run as Desktop" simulation
@chroma/linterFullFullSame rules; optional routes, .chr layout; no Fs backend simulation
chroma validateFullFullSchema + structure; does not boot Desktop or browser
chroma devOpens browser or DesktopPer dev.desktop / flagsChooses dev host, not production mode
chroma buildFullFullOne dist/ artifact for both
chroma installInstalls CLI, server, plugins, optional chroma-desktopSameDesktop binary used for develop workflow

Legend: Full = tool works the same whether you eventually ship Portable or Executable.

VS Code extension (Chroma-VSCode)

Publisher: targapps. Language ids: chroma (.chr), chroma-manifest, chroma-fs-config, chroma-plugin-manifest.

FeatureBehaviorMode notes
JSON Schema on manifestschroma.json, chroma.plugin.json, chroma-fs.jsonchroma-fs.json schema allows both backends; extension does not warn if you choose filesystem but only test in a browser tab
Chroma: Lint Project@chroma/linter project rulesPlugin folders, build.jsEntry, semver — host-agnostic
Save triggers.chr, chroma.json, plugin/fs manifestsDoes not lint index.html CDN drift
Snippets / LSPNot implementedN/A

Activation: workspaceContains:chroma.json or **/*.chr.

Entry point: src/extension.js bundles @chroma/linter; diagnostics collections chroma-schema and chroma-project.

Practical split: develop UI with chroma dev --no-desktop for live reload (Live reload); keep dev.desktop: true when you need Desktop bridge testing. The extension does not enforce either workflow.

@chroma/linter

ValidatesPortable / Executable
chroma.json against published schemasSame
Plugin chroma.plugin.json + folder presenceSame
chroma-fs.jsonSame — does not simulate IndexedDB vs disk
.chr layout, router paths (if present)Same
legacyLibraries in schemaAccepted when present; limited structural rules

CLI: npx chroma-lint --project . — exit code 1 on errors.

Chroma CLI (chroma)

CommandAffects runtime mode?
chroma newVendors plugins; sets dev.desktop per template
chroma devYes (dev only) — --no-desktop, dev.desktop, sets CHROMA_DEV_RELOAD=0 for Desktop develop
chroma buildNo — same output for both modes
chroma validateNo
chroma installInstalls optional chroma-desktop for develop
chroma addWrites legacyLibraries; does not change WASM target

Windows note: chroma validate structural-only behavior is documented in chroma.json reference.

Chroma Desktop as distributor, not linter

chroma-desktop is the Executable host:

  • Not listed in chroma.json plugins.
  • Versioned separately (Chroma-Desktop/VERSION).
  • Provides zip import, loopback static server, and Chroma-Fs bridge — see Desktop.

Building Desktop from source (cargo tauri build) is independent of chroma build for your app.

Chroma-Server (engine)

The dev server binary serves static files and optional browser live reload. It does not load plugins differently per mode; the browser or Desktop iframe loads plugins/loader.js.

SettingPortable devDesktop develop
Injects dev-reload.jsWhen reload enabledReload disabled for Desktop session
Serves plugins/YesYes (iframe loads same URLs)

Reference: Server.

On this page