The viewer ran a second highlighter over source the engine had already parsed
with a real grammar: Shiki, plus 56 pruned TextMate grammars shipped in
dist/textmate/. The classification now comes off that tree instead, so a file is
read by exactly the grammar that decided what its symbols are.
The swap is complete rather than flagged: @shikijs/core, @shikijs/engine-javascript
and @shikijs/langs are off the dependency list, scripts/prune-grammars.mjs and
`npm run build:textmate` are deleted, and check-ui-build.mjs asserts the
tree-sitter grammars in dist/extraction/wasm instead of dist/textmate.
The wire contract is unchanged — `[classId, text]` pairs with the class names
alongside — so the viewer's decoder and code blocks did not have to be rewritten.
Two classes are added to the six: `type` (a named type reference, painted at
plain ink) and `def` (the name a definition declares, weight 600), the latter
taken from the extractors' own definition tables so it cannot drift from what
indexing calls a definition.
Three differences are not cosmetic:
* Interpolations (`${…}`, `#{…}`, `$"{…}"`, f-strings) are classified as code,
not as string. The call-site overlay refuses to claim a token classed string,
so calls written inside interpolated strings now link.
* Built-in type words are emitted whole and classed `type` in every language.
The grammars disagree about whether `string` is a type_identifier or an
anonymous token inside a predefined_type, and TextMate scoped them
inconsistently too.
* 3 000 lines of TypeScript cost 24-41 ms instead of ~700 ms.
Given up deliberately: Liquid, Razor, YAML, Twig, XML and .properties render
plain. .svelte/.vue/.astro are classified through their <script> blocks, the same
delegation the SFC extractors do. Pulling html/css/vue out of tree-sitter-wasms
would cover them, but those ABI-13 builds are the known cause of shared-WASM-heap
corruption for every other language in the same process.
Measured parity, per-language before/after screenshots and the reproduction
recipe: docs/design/cg57-highlighting-parity.md.
ui/ — the codegraph ui viewer
The browser reader for an indexed project: Svelte 5 + Vite, built as static
files and served by the CLI over loopback. An npm workspace of the engine, so
npm ci at the repo root installs its toolchain; nothing here is a runtime
dependency of the engine and nothing here is published to npm on its own.
Design spec (every token, size and measurement):
../docs/design/codegraph-ui-design-spec.md.
Build
npm run build # from the repo root: tsc -> copy-assets -> this app
npm run build:ui # just this app, plus the dist assertion
npm run dev -w ui # Vite dev server on 127.0.0.1:5174
npm run check -w ui # svelte-check
npm run build emits dist/viewer/ (index.html + hashed assets).
scripts/check-ui-build.mjs then asserts the tree is complete, so a broken UI
build fails the release instead of shipping a CLI that serves a 404. The same
check runs again in scripts/build-bundle.sh (after the bundle stage copies
dist) and in scripts/pack-npm.sh (after each archive is unpacked).
Why dist/viewer and not dist/ui
src/ui/ is the engine's terminal UI (shimmer progress and its worker) and
tsc compiles it to dist/ui/. Pointing Vite there deletes those modules — the
CLI then dies at startup with Cannot find module '../ui/shimmer-progress' —
and would also leave the static server handing out compiled engine internals.
check-ui-build.mjs re-asserts the compiled engine is intact after every UI
build so that mistake cannot land twice.
Layout
src/
main.ts fonts + tokens, mounts App into index.html's #app
app.css design tokens (light/dark), reset, shell grid
App.svelte top bar / trail bar / main, global keys
lib/router.svelte.ts hash router: #/s/<id>, #/file/<path>, #/map, #/flow, #/entry
lib/trail.svelte.ts the walked path; mirrored into the `t` query param
lib/kinds.ts kind glyph letters
lib/map-model.ts the Map's deterministic layered layout (pure)
lib/flow-model.ts the Flow strip's card/link geometry + the end cap — a DAG (pure)
lib/filecode-model.ts the whole-file view: fixed line height, arcs, paging (pure)
lib/entry-model.ts the entry-points panel: rows, file groups, flow arming (pure)
lib/export-svg.ts the Flow strip and the Map as a standalone SVG (pure)
lib/export-image.ts rasterising that SVG to PNG, clipboard and download
lib/live.svelte.ts /api/events: two counters every screen refreshes from
lib/toast.svelte.ts the one transient note ("Index updated · reloaded")
components/ TopBar, TrailBar, KindGlyph, DriftBanner, Toast, ExportButtons, map/, flow/, symbol/, file/, entry/
views/ one component per route
Fonts (Archivo Variable, IBM Plex Mono) are vendored through @fontsource* and
emitted into dist/viewer/assets: a local reader must work offline and must not
announce the project to a font CDN.
Export
The Flow strip's header and the Map's side panel carry Copy image (a PNG on the clipboard) and Download SVG (a file for a README). Both render the light theme whatever the viewer is set to — an image is read on somebody else's screen — with 24px of paper around the drawing, a caption naming the path or the root, and a "CodeGraph" mark in the corner.
export-svg.ts serialises the layout object; it does not scrape the DOM.
buildFlowLayout and buildMapLayout already compute every rectangle, port and
curve before a component renders, so the image and the screen come from one
piece of arithmetic and cannot disagree — and the exporter is a pure function
that a test can run with no browser at all. The output is presentation-only SVG
(no script, no foreignObject, no external reference), which is what GitHub
will render in a README.
Fonts travel as font-family stacks rather than embedded bytes. An SVG loaded
as an image may not fetch a webfont, so a raster falls back to the platform's
own monospace; every fallback in the stack advances at ~0.6em like IBM Plex
Mono, so the code grid survives and only the letterforms change.
Routes
| hash | view |
|---|---|
#/ |
nothing selected |
#/s/<id>?hl=<line>&t=<trail> |
symbol view |
#/file/<path>?hl=<line> |
file view — outline in source order |
#/file/<path>?src=1 |
file view — the whole file's source, with ports and call arcs |
#/map?root=&depth=&tests=1 |
module map |
#/flow?from=&to= |
flow strip — the call path between two symbols |
#/flow?symbols=a,b,c |
flow strip — codegraph_explore's own question |
#/flow?t=<trail> |
flow strip — the trail you walked, read as a flow |
#/entry |
entry points — routes, files that run something, tests, hubs |
Entry points
#/entry draws /api/entrypoints as file groups, reusing the Symbol view's
.filegroup / .row shapes rather than inventing a second visual language for
"a list of code, grouped by where it lives". Three things about it are decisions,
not accidents:
- Routes group by where the URL is REGISTERED, not where it is served. A
router file is the shape a reader already has in mind; handlers scatter across
a package. The payload carries both, and the row's meta line names the handler
and its
file:line. - A row offers a flow only if it names a callable symbol.
/api/flowsearches the graph by NAME, and a file has none the path finder can look up — so route and hub rows carry aFlow ›chip and file and test rows do not. A chip that always failed would be worse than no chip. - No empty Routes box. A project with fewer than three resolvable routes is not a routed app, and the section is absent rather than empty; the panel falls back to the files that run something and the tests that exercise them.
buildEntryPanel is pure and keeps panel.rows exactly equal to the sections it
draws, the same identity the search palette rests its keyboard on.
Where the graph stops
A flow that does not reach everything it was asked about carries a
boundary on the wire, and buildFlowLayout turns it into an extra 240px node
one column past the symbol the path stopped at, joined by a dotted 2 4 link
labelled "end of static path" that deliberately has no arrowhead — an arrow
would point at a continuation, and the absence of one is the finding.
Two rules hold it together:
- The cap's height is arithmetic, like a card's.
endCapText()builds every sentence the cap shows andendCapHeight()measures them; the component then renders exactly what was measured. Change the wording in one and the other moves with it — they are the same function read twice. - One cap per stopping symbol, not per flow. Two paths that run out at the same place ran out for the same reason, and two caps side by side would read as two different findings.
The verdict itself is not computed here or in the server: it is
findDynamicBoundaries in src/graph/dynamic-boundary-report.ts, the same
detector codegraph_explore announces boundaries with.
Live updates
The viewer never polls. lib/live.svelte.ts holds one EventSource on
/api/events for the life of the page and exposes two counters:
indexTick— the graph moved (somebody synced). Every screen refetches: a rail is an answer about the whole graph, and a symbol gains a caller when some other file is edited, so filtering by the focused file would leave the rails quietly wrong. One request per sync.diskTick— source files changed on disk and the index has not caught up. Only the screen showing one of those files reacts, and what it does is draw a drift banner.
liveRefresh(file, refresh) is the three lines of bookkeeping that turns a
counter into a single call; the Map and the Flow strip instead read
live.indexTick straight inside the effect that already fetches them.
Reconnection is ours, not EventSource's: each failure closes the stream and
schedules ONE retry on a backoff that ends after eight attempts (~90 s), at
which point the top bar says "Not live" and nothing more is requested until the
tab is focused again. A degraded event — the server's watcher gave up — is
shown the same way and never answered with a poll.
Node ids and file paths are encoded per slash-separated segment, so
#/file/src/mcp/tools.ts stays readable and still round-trips a segment
containing a reserved character. Build hashes with symbolHref() /
fileHref() / mapHref() / flowHref() rather than by hand.