Caspian GitHub issue

• View as CJS
  • • Interaction with the format toggle
  • • Why this is cheap
• • Open questions
• • Out of scope

{"vibecode": {
    "doc": "github-puck-caspian",
    "status": "brainstorm — Caspian-specific tools the puck.uno site offers when viewing Caspian code",
    "parent": "../github.md",
    "sibling": "gitter.md",
    "scope": "features that only apply to Caspian code blocks or .casp files; not part of the general per-language formatter machinery"
}}

Caspian-specific rendering features that puck.uno (and Gitter post-V1) offers on top of the per-language format toggle. These are extras only Caspian gets — they exploit the Caspian→CJS transpiler that already lives in the engine.

View as CJS GitHub issue

A toggle next to every Caspian code block (or .casp file view) that swaps the displayed source from Caspian to its CJS representation. Click once to see what the engine actually consumes; click again to return to Caspian.

• Off by default. Author-faithful Caspian source is the baseline.
• Per-viewer sticky. Toggling on any Caspian block flips view-as-CJS on for every Caspian block on every page; stays on across sessions until flipped off.
• CJS is always pretty-printed per your JSON style. There's no "raw CJS" the author wrote — CJS is generated by the transpiler, so the displayed form uses the json section of your style.json (indent, line width, etc.).
• Independent of the format toggle. The Caspian format toggle reformats Caspian source per your Caspian style; view-as-CJS replaces the display entirely with CJS. They're separate switches that can be combined.

Interaction with the format toggle GitHub issue

For any Caspian block, two independent switches give four states:

Why this is cheap GitHub issue

The same Caspian→CJS transpiler that powers the Caspian format toggle, Differ's normalization, and the future Caspian web stack already produces the CJS — the view-as-CJS toggle just shows the intermediate output instead of running it back through the Caspian code generator. No new machinery required beyond the rendering switch and the toggle UI.

Open questions GitHub issue

• The toggle's UI shape: a small icon next to the format toggle? A dropdown letting the viewer pick a display mode (Caspian / CJS / future "alternate representations" like AST or Lua-target)?
• Should the CJS view show line-by-line correspondence with the Caspian source (clickable mapping, hover-highlight)? Useful for learning; non-trivial to implement.
• Are there other "view alternate representation" toggles worth offering down the road — AST tree, transpiler intermediate stages, the Lua target Lucy generates? If so, view-as-CJS is the first of a small family and should be designed with room to grow.

Out of scope GitHub issue

• Editing CJS directly. The CJS view is read-only; the user edits Caspian.
• View-as-CJS for languages other than Caspian. It's inherently Caspian-specific because CJS is Caspian's compilation target.