# dot-engine: a faithful pure-TypeScript port of Graphviz (no WASM) — plus markdown/SSG plugins and a VS Code extension

**URL:** <https://forum.graphviz.org/t/dot-engine-a-faithful-pure-typescript-port-of-graphviz-no-wasm-plus-markdown-ssg-plugins-and-a-vs-code-extension/3388>\
**Category:** Dev\
**Created:** [July 27, 2026, 11:02pm UTC](https://forum.graphviz.org/t/dot-engine-a-faithful-pure-typescript-port-of-graphviz-no-wasm-plus-markdown-ssg-plugins-and-a-vs-code-extension/3388 "2026-07-27T23:02:43Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sseely](https://avatars.discourse-cdn.com/v4/letter/s/74df32/32.png) [@sseely](https://forum.graphviz.org/u/sseely)\
**Post date:** [July 27, 2026, 11:02pm UTC](https://forum.graphviz.org/t/dot-engine-a-faithful-pure-typescript-port-of-graphviz-no-wasm-plus-markdown-ssg-plugins-and-a-vs-code-extension/3388/1 "2026-07-27T23:02:43Z")

</div>

Hi all — I’d like to share a project some of you may find interesting (or alarming): a faithful port of Graphviz from the C source to pure TypeScript.

**Engine** — [`@knowvah/dot-engine`](https://github.com/knowvah/dot-engine) (npm: `@knowvah/dot-engine`, EPL-2.0 like upstream):

- All eight layout engines are ported — dot, neato, fdp, sfdp, circo, twopi, osage, patchwork — plus the shared machinery around them (cgraph model, pathplan spline routing, record/HTML-like labels, arrowheads, pack, etc.).
- Output formats: SVG, xdot, dot, json, plain / plain-ext, cmapx / imap.
- Runs in the browser as a normal ES module: no WASM, no native binary, no emscripten, zero runtime dependencies. Full engine is ~233 KB gzipped (vs ~621 KB for the WASM build — WASM inlines the binary as base64, which barely compresses).

**“Faithful” is the operative word.** I treated the C source as the canonical specification and ported it branch-for-branch — including the odd corners, because decades of user-reported layout quirks are encoded in those special cases. Where the port preserves a C quirk deliberately (e.g. the `tee` arrowhead asymmetry, `checkPath`’s stale box count in dotsplines), that’s documented rather than “fixed”. Conformance isn’t eyeballed: every change is validated against the native `dot` binary as an oracle over a ~780-input corpus, per engine and per output surface, at a ±0.01 structural tolerance. The current matrix is public — [PARITY.md](https://github.com/knowvah/dot-engine/blob/main/test/corpus/PARITY.md) — dot/SVG is at 96.7% conformant with 0 unexplained divergences; every accepted delta carries a root-cause writeup (most of the irreducible ones come down to V8-vs-libm 1-ULP trig differences at genuine tie points, which this community will find unsurprising).

**Plugins** — [`dot-plugins`](https://github.com/knowvah/dot-plugins) turns the engine into drop-in DOT rendering for docs toolchains, all rendering at build time to inline SVG (no client JS needed):

- `@knowvah/vitepress-plugin-dot`, `@knowvah/eleventy-plugin-dot`, `@knowvah/docusaurus-plugin-dot` — fenced ````dot` code blocks in your markdown become diagrams.
- `@knowvah/dot-markdown-it` — the underlying markdown-it plugin, usable anywhere markdown-it runs.
- `@knowvah/dot-react` — a `<DotDiagram>` component for client-side rendering.

**VS Code** — `knowvah.dot-vscode` (“DOT (Graphviz) Preview & Syntax”): syntax highlighting for `.dot`/`.gv`, a live SVG preview pane, and DOT fenced-block rendering inside VS Code’s built-in markdown preview — no Graphviz install required, since the engine ships inside the extension.

**Why do this at all?** Partly because when GitHub shipped Mermaid support, the discussion here ([thread 998](https://forum.graphviz.org/t/github-adding-support-for-mermaid-diagrams/998)) landed on: Graphviz is a large C library, and even compiled to WASM it’s a heavy dependency for platforms to adopt. I wanted DOT to be embeddable anywhere JavaScript runs — markdown pipelines, static-site generators, browsers, edge runtimes with strict CSP that won’t load `.wasm` — with the real Graphviz layouts, not an approximation.

Being upfront about the cost: per-layout it’s ~3.5–4.5× slower than the WASM build (V8 vs compiled C — a stable constant factor, not a blow-up). In absolute terms that’s under ~25 ms up to a few hundred nodes, so for typical diagram sizes it’s imperceptible; for huge graphs the WASM build or native remains the right tool, and the SSG plugins sidestep it entirely by rendering at build time.

I’d genuinely value this community’s scrutiny — conformance bug reports with a `.dot` file attached are the most useful thing you could send me. And if anyone from the core team is curious about the porting notes (C `round()` semantics, calloc-zero vs `undefined` hazards, the places where layout depends on evaluation order), I kept a detailed decision journal in the repo.

* * *

---

<div class="post-metadata">

**Author:** ![oliversalzburg](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/oliversalzburg/32/2010_2.png) [@oliversalzburg](https://forum.graphviz.org/u/oliversalzburg)\
**Post date:** [August 1, 2026, 11:43am UTC](https://forum.graphviz.org/t/dot-engine-a-faithful-pure-typescript-port-of-graphviz-no-wasm-plus-markdown-ssg-plugins-and-a-vs-code-extension/3388/2 "2026-08-01T11:43:45Z")

</div>

> [@sseely](#):
>
> I treated the C source as the canonical specification and ported it branch-for-branch — including the odd corners, because decades of user-reported layout quirks are encoded in those special cases.

[It’s nice to see that you took that much effort.](https://github.com/knowvah/dot-engine/blob/main/CLAUDE.md?plain=1#L11-L13)