Class Diagrams for Modern Type Systems: Diagram-as-Code and Source Generation with typeDiagram

A practical guide to class diagrams for modern type systems, including records, discriminated unions, and tagged unions. Generate TypeScript, Rust, C#, F#, Go, Python, Dart, PHP, and Protobuf types from one diagram, render SVG via pluggable hooks, and embed in Markdown — all diagram-as-code, all open source.

If you searched for a class diagram tool for modern type systems, a way to generate types from a diagram, or an AI-ready diagram-as-code workflow, this post answers the three questions developers actually ask in 2026:

  1. How do I draw a class diagram for records, discriminated unions, and tagged unions?
  2. How do I generate TypeScript, Rust, C#, F#, Go, Python, Dart, PHP, or Protobuf types from one diagram?
  3. How do I get an AI-assisted class diagram that stays in sync with my codebase?

The short answer: typeDiagram. It is a full diagram-as-code ecosystem — a tiny DSL for records and tagged unions, a parser, a layout engine, an SVG renderer with pluggable render hooks, a source generator for nine languages (TypeScript, Python, Rust, Go, C#, F#, Dart, PHP, Protobuf), a Markdown plugin, a CLI, and a VS Code extension. Language-neutral, open source, and designed to slot into Markdown, VS Code, and MCP-based AI workflows.

Class diagrams for the way we actually write types today

Classical UML class diagrams were built around classes, methods, inheritance, visibility, and multiplicities. They still have their place, and excellent tools exist for drawing them.

But a lot of modern code has grown beyond that shape. TypeScript has discriminated unions. Rust has enums with payloads. Swift has enum cases with associated values. Kotlin has sealed classes. C# 10 added records. Python has dataclass and Literal tag fields. F# and OCaml have had these features for decades. Almost every mainstream language now has a way to express records and tagged variants as first-class types — whether you lean OOP, FP, or somewhere in between.

Drawing a Rust Result<T, E> or a TypeScript type Event = { kind: "click"; x: number } | { kind: "scroll"; y: number } as a traditional class diagram pushes you into stereotypes, notes, or inheritance hierarchies that do not match the code.

typeDiagram is a class diagram tool built specifically for this style. Just records and tagged variants, with a rendering that matches how the code is actually written — and a source generator that turns the picture back into code. It sits next to your existing UML or class diagram workflow, it does not replace it.

What is diagram-as-code, and why should you care?

Diagram-as-code means your diagram lives in a text file, checked into git, rendered by a build step. You get code review, diff, blame, version history, CI, and the ability to embed the rendered image into Markdown docs. This is why Mermaid grew from nothing to 85,000 GitHub stars and PlantUML became the standard for architecture docs.

typeDiagram is diagram-as-code, but focused. It does one thing: type diagrams. One small DSL, one deterministic SVG output, one Markdown integration, one VS Code extension, one CLI.

typeDiagram syntax in 30 seconds

record User {
  id: UUID
  email: string
  role: Role
}

union Role {
  Admin
  Member { team: string }
  Guest { expiresAt: DateTime }
}
 

That is a complete, valid diagram. Paste it into the playground and you get an SVG back with User and Role connected by an edge, each variant of Role shown as its own row with its payload.

No classes. No methods. No stereotypes. Just the shape of your data.

Where typeDiagram fits alongside Mermaid and PlantUML

Mermaid and PlantUML are excellent, general-purpose diagram-as-code tools. Mermaid's classDiagram and PlantUML's UML support cover a huge range: sequence, state, flowchart, ER, deployment, C4. For most of those jobs, they are the right pick, and typeDiagram does not try to replace them.

typeDiagram is focused. It does one thing: class diagrams for records and tagged variants, end-to-end. That focus buys three things general UML renderers do not offer:

Pair them freely. Mermaid for sequence and flowchart, PlantUML for C4 and deployment, typeDiagram for the type layer that also generates your code.

Generate TypeScript, Rust, C#, F#, Go, Python, Dart, PHP, and Protobuf types from one diagram

This is the feature that changes the workflow. Write the diagram once, get idiomatic types in every language your services use:

Try it in the converter — paste a diagram on the left, pick a language on the right, copy the source into your project. Round-trip works too: paste existing types, get a diagram back.

This is the source generator use case that C# Roslyn fans already know, generalised to every language and driven by a visual contract instead of attributes. One diagram, N languages, zero drift.

Render hooks: style, annotate, and extend the SVG without forking

The renderer exposes a hook API at every stage of the pipeline — before layout, per-node, per-row, per-edge, background, and post-render. Hooks are where the ecosystem opens up:

Hooks compose, are fully typed, and return Result<T, E> — no thrown exceptions, no surprise crashes during batch rendering. The same hooks work in the CLI, the VS Code extension, and the browser playground.

AI-assisted class diagrams and MCP integration

"class diagram ai" searches grew +350% over the past twelve months. "mermaid mcp" grew +800%. Developers want their AI tools to draw and read diagrams.

typeDiagram is built for this. The DSL is tiny, deterministic, and easy for a large language model to emit correctly. The Markdown integration means an agent can drop a diagram into a doc and have it render. The CLI and library have stable, typed public APIs so an MCP server can expose render, parse, and generate as tools. An agent that reads your codebase can emit a typeDiagram, a human reviews the SVG, and the same diagram generates the updated TypeScript — closing the loop.

If you are building an AI doc-gen pipeline, typeDiagram gives you a diagram format an LLM can write, a renderer that produces deterministic SVG, and a source generator that closes the diagram-to-code gap.

Markdown, VS Code, CLI, web playground

typeDiagram ships four surfaces:

All four consume the same public API. No duplicated parsing or layout logic. What you see in the playground is exactly what CI renders.

"I already use Mermaid or PlantUML — do I need typeDiagram?"

Add, don't switch. Keep Mermaid or PlantUML for sequence, flowchart, state, ER, C4, and deployment diagrams. Reach for typeDiagram when you want the type layer — the records, the discriminated unions, the domain model — to also generate code in nine languages and to render through customisable hooks. They render side-by-side in the same Markdown file.

Getting started in 60 seconds

npm install -g typediagram
echo 'record User { id: UUID, email: string }' > user.td
typediagram user.td -o user.svg
typediagram user.td --emit typescript > user.ts

That is the full loop: diagram, SVG, typed source. No server, no JVM, no configuration.

Try the playground, browse the docs, or grab the VS Code extension and start drawing types the way your code actually looks.

FAQ

Is typeDiagram free and open source? Yes. MIT licensed, on npm and GitHub.

Does it replace UML? No. UML class diagrams cover a much wider surface — methods, inheritance, visibility, multiplicities — and UML has thirteen other diagram types. typeDiagram covers the type layer specifically: records, unions, variants, references, with source generation built in.

Can I embed diagrams in Markdown? Yes — a Markdown-it plugin ships in the core package. Fenced typediagram blocks render to inline SVG.

Does it work offline? Yes. Pure JS/TS, no network calls, deterministic output.

What about C4, ArchiMate, ERD? Out of scope. typeDiagram is the type layer. Pair it with Structurizr or Mermaid for architecture.

Is there a hosted version? The playground runs entirely in your browser. Nothing is uploaded.

Draw your types the way your compiler sees them. That is the whole pitch.