8. phaze-glow

1. phaze-tsplugin                  ← editor (TS Language Service)
2. phaze-compile                   ← build-time AST rewriting
3. phaze-vite                      ← island HMR + chunking helpers
4. phaze-astro                     ← Astro integration (island model)
5. phaze-cloudflare                ← native Cloudflare Workers adapter (whole-page)

─── Editor stack ────────────────────────────────────────────────────
6. phaze-language-tools            ← Volar LSP backend (.phaze → virtual .tsx)
7. phaze-vscode                    ← VSCode extension (grammar + LSP client)
8. phaze-glow                      ← VSCode theme + halo runtime  ← you are here

madenowhere.phaze-glow is the VSCode visual identity for the Phaze stack — a neon dark color theme and an optional text-shadow halo runtime, both opt-in, both independent of every other tooling package. Install it for the chromatic look you see across the docs, the screenshots, the marketing pages. It’s the only package in the stack that exists for aesthetics.

#8 is fully decoupled from #7 (phaze-vscode). The theme works on any language; the halo runtime patches VSCode’s workbench HTML regardless of what file you have open. You don’t need .phaze files to use it. Pair it with #7 for the full Phaze visual identity, but each works standalone.

The color theme

Pick it via Command Palette → Color Theme → Phaze Glow.

The palette is small and intentional — five chromatic accents on a single dark background:

Color	Hex	Used for
Hot pink	`#ff00fb`	`.phaze` fence markers, active tab, keyword brackets
Bright cyan	`#03e6ff`	git-modified, selection, list focus
Mint / teal	`#09fbd3`	class names, HTML attributes
Yellow	`#f5d300`	keywords, storage modifiers
Neon green	`#00ff59`	git-added
Coral red	`#ff5370`	invalid / errors
Editor background	`#1a1a1a`	every panel — editor, sidebar, panel
Foreground	`#eeffff`	default text — slightly off-white for the chromatic shadows to pop

The same colors phaze-compile uses for its terminal output (size reports, diagnostic code-frames) and that the docs use across the site. There’s no “light variant” — the palette only makes sense on dark.

The halo runtime

Phaze Glow ships with an opt-in workbench patcher that adds a chromatic text-shadow to each accent color, tuned by the phaze.brightness setting. The pattern is borrowed from Synthwave ‘84 / code-glow — VSCode’s renderer doesn’t natively support per-token text-shadow, so the only path is to inject a <script> into the workbench HTML that mutates the token stylesheet at runtime.

Enable / disable

Command Palette → Phaze: Enable Glow — patches workbench.html.
VSCode prompts to reload — accept.
After reload, VSCode may show “Your installation appears corrupt” — this is expected. Every workbench-patching extension triggers it (Synthwave ‘84, code-glow, Customize UI, …). Pick “Don’t show again” on the notification.

To remove the halo: Command Palette → Phaze: Disable Glow — strips the patch and reloads.

Brightness

The phaze.brightness setting (range 0.0–1.0, default 0.45) controls the alpha applied to each text-shadow:

{
  "phaze.brightness": 0.65   // brighter halo
}

After changing the value, re-run Phaze: Enable Glow to bake the new value into the workbench script. Brightness isn’t hot-reloaded — it’s interpolated into the runtime template at enable-time so the per-load cost is one replace per token rule, not a MutationObserver re-evaluation on every settings change.

Skip the per-token glow

{
  "phaze.disableGlow": true   // chrome-only — cursor, gutter, bracket match
}

Keeps only the editor-chrome glow (cursor halo, gutter bracket-match, line-number active line) without the per-token text-shadow. Useful if the syntax glow reads as too noisy at any brightness.

How the patcher works

Phaze: Enable Glow does three things, all in src/extension.js:

                        Command Palette
                       Phaze: Enable Glow
                              │
                              ▼
         ┌──────────────────────────────────────────────┐
         │ 1. Locate workbench HTML across VSCode       │
         │    layouts (electron-browser / -sandbox      │
         │    × workbench.html / workbench.esm.html)    │
         └──────────────────────────────────────────────┘
                              │
                              ▼
         ┌──────────────────────────────────────────────┐
         │ 2. Read src/glow/template.js + chrome.css,   │
         │    interpolate [BRIGHTNESS] (alpha hex),     │
         │    [DISABLE_GLOW] (bool), [CHROME_STYLES]    │
         │    (CSS), write to phaze-glow.js in the      │
         │    workbench dir                             │
         └──────────────────────────────────────────────┘
                              │
                              ▼
         ┌──────────────────────────────────────────────┐
         │ 3. Inject <script src="phaze-glow.js"></script>│
         │    inside <!-- PHAZE GLOW --> markers, just    │
         │    before </html>                              │
         └──────────────────────────────────────────────┘
                              │
                              ▼
         VSCode prompts to reload — runtime takes effect

At workbench-load time, the injected script runs a MutationObserver for the .vscode-tokens-styles element, finds each color: #XXXXXX; rule matching a Phaze Glow palette color, and rewrites it to include text-shadow: 0 0 2px #XXXXXX{BRIGHTNESS_HEX}. The brightness-to-hex conversion turns the 0–1 float into a 00–FF alpha byte appended to the color (0.45 → 73, giving #ff00fb73 = pink at ~45% alpha).

The marker comments ( / ) bracket the inserted script so Phaze: Disable Glow can strip it precisely without regex-matching the script src — forgiving against VSCode template drift between versions.

Workbench-version drift

resolveWorkbenchPaths() in extension.js handles two axes of VSCode-internal layout drift:

Electron base directory: electron-browser (≤ v1.70 and ≥ v1.102) vs electron-sandbox (v1.71–v1.101).
HTML filename: workbench.html (legacy) vs workbench.esm.html (newer ESM-shaped workbench).

The function tries all four combinations of (base × name) and returns the first existing file. If nothing matches, the extension surfaces an error pointing the user to file an issue with their VSCode version — every workbench-patching extension has the same drift surface, and the error path makes it actionable rather than silent.

Trade-offs

The same trade-offs every workbench-patching extension carries:

VSCode auto-updates clobber the patch. When VSCode auto-updates, it replaces workbench.html with the fresh shipped copy — the marker-bracketed script tag is gone. Re-run Phaze: Enable Glow after each VSCode update.
Needs write access to VSCode’s install dir. Fine for per-user installs (most macOS / Windows installs); system installs may require relaunching VSCode with admin privileges. The extension catches EACCES / EPERM and surfaces an admin-privilege error.
The “installation corrupt” banner shows once. VSCode’s tampering detection notices the modified workbench.html on first reload after enable. The banner is dismissable (“Don’t show again”) and stays dismissed across reloads.

These are inherent to the patcher pattern — there’s no API path. If VSCode ever ships per-token text-shadow support natively, the runtime layer disappears and the theme alone (which is a clean themes/*.json contribution, no patching) still works.

Why it’s separate from phaze-vscode

Three reasons, all about decoupling visuals from language tooling:

The theme works on any language. A user who likes Phaze Glow’s palette but writes Python all day shouldn’t need to install .phaze LSP machinery.
The LSP works under any theme. A user who likes Solarized but ships .phaze files shouldn’t have their colors hijacked.
Patching contracts differ. #7’s LSP client respects VSCode’s extension contract — no workbench modifications, no "installation corrupt" banner, no admin permission requirements. #8’s halo runtime breaks all three. Splitting means #7 stays in the clean-contract lane (relevant for users / orgs that disallow workbench-patching extensions) while #8 is the deliberate opt-in.

The two ship as separate VSIX files with separate version histories — so the LSP can iterate on phaze-compile’s pace while the theme stays stable.

Install

code --install-extension madenowhere.phaze-glow

Or search “Phaze Glow” by publisher madenowhere in the Extensions view.

To pair with phaze-vscode (#7):

code --install-extension madenowhere.phaze-vscode
code --install-extension madenowhere.phaze-glow

Then switch theme via Command Palette → Color Theme → Phaze Glow, and optionally enable the halo via Command Palette → Phaze: Enable Glow.

Files

Path	Role
`package.json`	Extension manifest. Contributes the theme, two commands (`Phaze: Enable Glow` / `Phaze: Disable Glow`), and two settings (`phaze.brightness` / `phaze.disableGlow`).
`themes/phaze-color-theme.json`	The Phaze Glow color theme — full token-color + workbench-color spec.
`src/extension.js`	Activation entry. Registers the two commands, resolves the workbench HTML, writes the runtime script.
`src/glow/template.js`	Runtime injected into the workbench DOM. `MutationObserver` for `.vscode-tokens-styles`, rewrites color rules to add `text-shadow`.
`src/glow/chrome.css`	Editor-chrome glow (cursor, gutter, line numbers, bracket match).